Skip to content

Some additional Jenkinsfile improvements#39661

Merged
vdemeester merged 14 commits intomoby:masterfrom
thaJeztah:jenkinsfile_improvements
Aug 6, 2019
Merged

Some additional Jenkinsfile improvements#39661
vdemeester merged 14 commits intomoby:masterfrom
thaJeztah:jenkinsfile_improvements

Conversation

@thaJeztah
Copy link
Copy Markdown
Member

playing with some changes to simplify stages, make the steps more consistent, and to move some steps around to reduce time and optimise for parallel stages

Jenkinsfile Outdated
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, so looks like "validate" needs to have privileged;

[2019-08-03T18:16:40.092Z] + docker run --rm -t -v /home/ubuntu/workspace/moby_PR-39661-3CKP7XCGKUQMONDQU2RSP42V5SYBDIVL7PRW2C4KIVVRW2B5LUCQ/bundles:/go/src/github.com/docker/docker/bundles -v /home/ubuntu/workspace/moby_PR-39661-3CKP7XCGKUQMONDQU2RSP42V5SYBDIVL7PRW2C4KIVVRW2B5LUCQ/.git:/go/src/github.com/docker/docker/.git --name docker-pr9 -e DOCKER_GITCOMMIT=9b16baed380e8bf01675742438cb957733c0501f -e DOCKER_GRAPHDRIVER docker:9b16baed380e8bf01675742438cb957733c0501f hack/validate/default
[2019-08-03T18:16:40.656Z] mount: permission denied
[2019-08-03T18:16:40.657Z] Could not mount /sys/kernel/security.
[2019-08-03T18:16:40.657Z] AppArmor detection and --privileged mode might break.
[2019-08-03T18:16:40.657Z] mount: permission denied
script returned exit code 32

@thaJeztah thaJeztah force-pushed the jenkinsfile_improvements branch from b588501 to 5a42229 Compare August 3, 2019 18:22
@thaJeztah
Copy link
Copy Markdown
Member Author

dang; unit-tests also require privileged; we should check if we really need that;

[2019-08-03T18:28:45.994Z] + docker run --rm -t -v /home/jenkins/workspace/moby_PR-39661-3CKP7XCGKUQMONDQU2RSP42V5SYBDIVL7PRW2C4KIVVRW2B5LUCQ/bundles:/go/src/github.com/docker/docker/bundles --name docker-pr10 -e DOCKER_GITCOMMIT=2c137b8bdba4a02500b2c2fe536ef677264cfd2c -e DOCKER_GRAPHDRIVER docker:2c137b8bdba4a02500b2c2fe536ef677264cfd2c hack/test/unit
[2019-08-03T18:28:46.356Z] mount: permission denied
[2019-08-03T18:28:46.356Z] Could not mount /sys/kernel/security.
[2019-08-03T18:28:46.356Z] AppArmor detection and --privileged mode might break.
[2019-08-03T18:28:46.356Z] mount: permission denied
script returned exit code 32

@thaJeztah thaJeztah force-pushed the jenkinsfile_improvements branch 2 times, most recently from 95a684e to e1a280d Compare August 3, 2019 18:36
@thaJeztah
Copy link
Copy Markdown
Member Author

Argh.. jenkins is acting up


[2019-08-03T18:36:41.582Z] using credential docker-jenkins-github-credentials
[2019-08-03T18:36:41.587Z] Cloning the remote Git repository
[2019-08-03T18:36:41.587Z] Cloning with configured refspecs honoured and without tags
[2019-08-03T18:36:41.638Z] Cloning repository https://github.com/moby/moby.git
[2019-08-03T18:36:41.845Z] ERROR: Failed to clean the workspace
[2019-08-03T18:36:41.845Z] jenkins.util.io.CompositeIOException: Unable to delete '/home/ubuntu/workspace/moby_PR-39661-3CKP7XCGKUQMONDQU2RSP42V5SYBDIVL7PRW2C4KIVVRW2B5LUCQ'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
[2019-08-03T18:36:41.845Z] 	at jenkins.util.io.PathRemover.forceRemoveDirectoryContents(PathRemover.java:86)

@thaJeztah thaJeztah force-pushed the jenkinsfile_improvements branch 2 times, most recently from a4eaa11 to f461996 Compare August 3, 2019 18:43
This patch removes the manual steps to resolve the Git commit, and
instead, uses the `GIT_COMMIT` that's set by Jenkins's Git plugin.

Behavior changes slightly, because `GIT_PLUGIN` contains the full
commit-sha, not the short one.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Both of these tests are fairly short, and shouldn't interfer with
eachother, so we can combine them and re-use the same dev-image
(so that it'll only be built once).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Having this information can help debugging issues in CI (which could
be caused by missing/incorrect configuration of the machines).

We ping to a fixed version of the script, because this script is ran
directly on the host, and we don't want pull-requests modifying this
script to have direct access to the machines.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah force-pushed the jenkinsfile_improvements branch from f461996 to 1f8ac35 Compare August 3, 2019 18:50
The .git mount is only needed for the DCO check, and for building
the binaries if `DOCKER_GITCOMMIT` is not set.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah force-pushed the jenkinsfile_improvements branch from 1f8ac35 to ad28fec Compare August 3, 2019 19:50
}
}
stage("Run tests") {
stage("Docker-py") {
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was a bit cautious with the order of these test, because they all bind-mount the bundles directory, and some of the tests will clean that up, which makes archiving artefacts from previous stages complicated (not sure if there's a recommended approach for that?)

binary-daemon \
dynbinary-daemon \
test-integration-flaky \
test-integration \
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably split this up into separate stages as well, but here I was also cautious because we want to archive artifacts

@thaJeztah
Copy link
Copy Markdown
Member Author

Okay, this is all green now; we can do some further splitting-up and organising after this. We should also look at storing the docker-py junit.xml, so that it can be shown in the Jenkins UI

This is what it looks like with these changes:

Screenshot 2019-08-04 at 00 18 26

ping @zelahi @tiborvass @seemethere @andrewhsu PTAL

Copy link
Copy Markdown
Contributor

@zelahi zelahi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I left one comment. But really liking how the different stages are looking

@@ -36,35 +37,82 @@ pipeline {
steps {
sh 'docker version'
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was wondering, does the docker version and docker info need to be printed out?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it helps to find out which version and graph driver has been configured for the node.

unless your question is more along the lines of, "why does docker info have the server version info but not the client version info in the output?"

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the idea of printing these is to help with debugging (e.g. why does something fail on X, but pass on Y, which could be due to a different version of docker installed, or a different configuration.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh thanks for clearing that up! I was wondering if it was left here for debugging purposes. It does make sense to have both since docker info doesn't show the client info

@andrewhsu
Copy link
Copy Markdown
Contributor

I don't think locking down check-config.sh to a fixed version in a2ad56d will help that much in preventing a person creating a PR to run arbitrary code. The PR author has access to the other Jenkinsfile step entry points.

As long as there is nothing interesting on the node that the user can get access to and as long as the admins of jenkins control the resources, the Jenkinsfile entry points should not have to be constructed much different than circleci and travis entry points.

Copy link
Copy Markdown
Contributor

@andrewhsu andrewhsu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

can remove a2ad56d in a separate PR in order to get these improvements in first

@seemethere
Copy link
Copy Markdown
Contributor

@andrewhsu more-so we shouldn't have the Jenkinsfile run any arbitrary shell scripts anyways.

@thaJeztah
Copy link
Copy Markdown
Member Author

I don't think locking down check-config.sh to a fixed version in a2ad56d will help that much in preventing a person creating a PR to run arbitrary code. The PR author has access to the other Jenkinsfile step entry points.

True, but the other ones are running inside the container, not on the host (although I spotted the make clean, which could be abused)

parameters {
booleanParam(name: 'unit', defaultValue: true, description: 'x86 unit tests')
booleanParam(name: 'unit_validate', defaultValue: true, description: 'x86 unit tests and vendor check')
booleanParam(name: 'janky', defaultValue: true, description: 'x86 Build/Test')
Copy link
Copy Markdown
Contributor

@zelahi zelahi Aug 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this is more of a knitpick but would it be useful to modify the description of janky. The reason is what's the difference between the tests being ran in unit_validate and janky?

Copy link
Copy Markdown
Contributor

@seemethere seemethere Aug 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It really should be named integration-cli although I have no idea what the difference now between janky and experimental is now

nvm, I can see that experimental sets DOCKER_EXPERIMENTAL=y, but still not entirely sure what functionality is still hidden behind experimental

@tiborvass
Copy link
Copy Markdown
Contributor

@andrewhsu @seemethere I don't understand #39661 (comment) but @thaJeztah made sure that only the people authorized modifying the Jenkinsfile can modify what check-config shell script to run, as the commit is hardcoded in the Jenkinsfile.

dynbinary-daemon \
test-integration-flaky \
test-integration \
cross
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be in an other stage. We can do that in a followup

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♂️ ah, we actually discussed that, forgot doing it in the end.

Yes, some more improvements can be made overall (wrt artifacts as mentioned as well). Thought this was a good starting point to split up some steps

@tiborvass
Copy link
Copy Markdown
Contributor

Ping @cpuguy83 @vdemeester

Copy link
Copy Markdown
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants