WIP: Create ploigos-jenkins-plugins to bundle plugins for disconnected environments

[adamgoossens]

I've got this as a WIP for initial review and feedback. My testing so far has been positive but I still have more to do. I figure if this container goes in first and is built, then a follow-up PR can go into the Ploigos operator to change the Jenkins DC to include it as an initContainer.

---

This container is built with a two-stage process. The first uses the existing Jenkins image so as to use the install-plugins.sh script to pull down the plugins listed in ploigos-plugins.txt. The second stage copies all of these plugins into a ubi-minimal container.

The container can then be used as an initContainer for a Jenkins deployment, with the Jenkins PV mounted into the container. The content can then be copied into $JENKINS_HOME/plugins.

This container can then be shipped into disconnected environments to provide all the required plugins to support Ploigos deployment.

[andykrohg]

By the way, looks like the checks failed because they require repository secrets that aren't exposed to forks. We'll also need to add this image build to .github/workflows/publish.yaml

[itewk]

@adamgoossens @andykrohg shouldt the install of any plugins be part of the operator and not us trying to maintain a jenkins image when red hat already ships a (importanltys upported) jenkins image? the entire point of all of this is not to require a bunch of jenkins plugins the only two we install are:

• ansicolor - which i just a nice to have and not required
• gitea - which again, is a nice to have if using gitea for your source control, but if using something else, like gitlab, wouldn't be used and therefor maintaing this jenkins image would be for the sole purpose of having the gitea plugin already installed and then taking on all the overhead of keeping plugin versions and jenkins and etc up to date in this image.

[andykrohg]

I agree the list of plugins we require on top of the RH Jenkins image should be kept to a minimum, if not non-existent. However, installing plugins by way of plugins.txt is different than installing through the front end (and then restarting the server, if necessary). At first, we started with Gitea, but realized that installing that plugin by itself broke other things on the server (kubernetes plugin, blue ocean, or Multibranch Pipeline). So the list has grown because achieving functionality for all the things we need requires more stuff to be explicitly called out in plugins.txt.

We could bypass the requirement to maintain a separate image but in order for operator deployments to continue to be successful, we'd need to either

1. Maintain a locally packaged collection of plugin files anyway, or
2. Have an internet connection to update on command, which is no go in disco

[itewk]

@andykrohg i would think the approach for the plugins for Jenkins should be like that of the operator hub and container images. step 0 is downloading any necissary plugins to disk and sneakernetting them in and putting them in an internal repo, and then configure jenkins to pull its updates/plugins from that internal repo rather then the internet.

[adamgoossens]

@itewk I understand what you're saying. If we do follow the OperatorHub model this approach allows for that, to a a point: this becomes an exposed relatedImage of the CSV, it's pulled down automatically by catalog mirroring tools, and no extra work on the part of the user is required.

I suppose it depends on how much extra work we want users to do in order for the Operator to install and work successfully in disconnected environments, and how many assumptions we're willing to make about the users hosting their own internal repository for Jenkins plugins. I personally lean towards assuming nothing and minimising friction to getting started but I know there are trade-offs there.

I do agree though that best case would be not requiring any extra plugins.

[adamgoossens]

Thinking further, another option might be to ship the images but also expose a parameter in the operator to allow configuring an update center URL. If the update center URL is configured we use that as the plugin source and configure Jenkins appropriately. If it doesn't, we use our bundled plugins.

[itewk]

I am going to differ to @kharyam and @dwinchell on this one.

[andykrohg]

@dwinchell @kharyam curious on your thoughts here as well, but to @itewk 's point about consistency with sneakernetting patterns, any way we approach this will require us to maintain a collection of plugins that we need to port into a disconnected environment. The reasons I like using an init container as the vehicle for this:

1. It gives us better performance. Copying between containers in a pod will be faster than downloading plugins, even from a locally hosted plugin server, this improving jenkins initial boot time.
2. We only need the plugins on jenkins' first boot. So it doesn't make sense to keep a persistent plugins server around anyway, and the init container is, of course, ephemeral.
3. We're already sneakernetting container images as part of step 0. Simply adding this image to the list would require less work than creating a new process for serving jenkins plugins from nexus, etc.

[andykrohg]

Lgtm 👍

[dwinchell]

I talked to @andykrohg about this

I like the update center path better from an architectural perspective, but it sounds like Jenkins' implementation of that is not great. They tried it and wound up with failing transitive dependencies. Let's use the sidecar and move forward. When we get to day 2 operations, we'll probably have to revisit this.