Feature/deterministic jenkins plugins #64
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
From jenkinsci/docker@22f3f03. It might be deprecated, but for this usecase it's much more lightweight than the "plugin installation manager tool" which requires Java, which is not installed in our Docker image. We could use this in a separate stage in Dockerfile but then apply.sh would no longer work outside the Docker image, which would make development more complicated right now. In future, when we migrated our shell scripts to a different technology, this decision might change. https://www.jenkins.io/doc/book/installing/offline/
This makes sure to get deterministic version of plugins and all dependencies. Removes waitForPluginInstallation() as this leads to failure because we install all plugins in arbitrary order. This order might lead to plugins being installed before their dependencies. As we do a restart at the end all plugins are loaded in proper order by Jenkins on startup.
These are installed in the base image but are awfully outdated.
Neither necessary to run as root, nor to run in host network.
Error message was: scripts/apply.sh: line 167: [: node/gke-xyz-default-node-pool-ba431f08-jr9h
schnatterer
force-pushed
the
feature/deterministic-jenkins-plugins
branch
from
4fd0489
to
a6f5432
Compare
This is helpful when e2e.groovy is used on a jenkins instance that contains other jobs, not only the gitOps SCM Folders. For non-folder jobs we would otherwise run into this exception: java.lang.IllegalStateException: Optional.get() cannot be called on an absent value ... at JenkinsHandler$_buildJobList_closure1.doCall(e2e.groovy:94)
This provides more deterministic results, because the install-plugins.sh loads specific versions of the plugins but the latest version of each dependency. We could resolve this more fiercely by using a complete dependency tree that can be create like this: https://gist.github.com/Lucasus/1a6b8df71425c790361c
Also use retries for better performance, but make sure to not wait endlessly.
schnatterer
force-pushed
the
feature/deterministic-jenkins-plugins
branch
from
be1e840
to
16a3c85
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now, playground loops endlessly while applying.
Reason: Jenkins plugins installation never finishes.
How could this problem appear without us having changed anything?
The current mechanism we use to install plugins on Jenkins via HTTP (plugin-center) always installs the latest version, even if we pass a deterministic plugin version. However, is seems to only install the required plugin and not the dependencies.
With the latest version of Docker Plugin now being 1.2.3 we can see the following error on the Jenkins UI:
This seems to lead to the Docker Plugin not being loaded and so our check for the plugin never succeeds, resulting in the endless loop.
Solution:
Install deterministic versions of plugins including their dependencies.
Jenkins offers multiple solutions for this - a java-based plugin installation manager tool or a shell script, both contained in the official images. This PR uses the shell plugin CLI. It might be deprecated, but for this usecase it's much more lightweight than the "plugin installation manager tool" which requires Java, which is not installed in the playground Docker image.
We could use this in a separate stage in Dockerfile but then apply.sh would no longer work outside the Docker image, which would make development more complicated right now.
In future, when we migrated our shell scripts to a different technology, this decision might change.
Minor fixes
Not related to the original issue the following things have been improved boy scout rule style:
This provides more deterministic results, because the install-plugins.sh loads specific versions of the plugins but the latest version of each dependency.
We could resolve this more fiercely by using a complete dependency tree that can be create like this
groovy:3.0.8-jre11'instead of `groovy:jdk11'