jenkins-bootstrap-shared VS blog

You can capture plugins and Jenkins versions using the script console to provision a second pristine Jenkins for additional testing like upgrade testing. I go deeper into this with complete immutable Jenkins infrastructure with jenkins-bootstrap-shared.

I recommend capturing your plugin versions. You can do it via maven or gradle. You could use the script console scripts on Jenkins. For testing upgrades you would need other means.

Jenkins as immutable infra

You can do this by script console yourself and use the community docker image. Alternately, you can try out jenkins-bootstrap-shared project I made which pulls Jenkins into a JKD8 container (I plan to upgrade it to OpenJKD11 since Jenkins now supports that).

Here's how I have it scripted. (documentation : https://github.com/samrocketman/jenkins-bootstrap-shared/tree/main/scripts/upgrade )

I forgot to mention I have an unpublished blog post on the topic. iptables man pages are a good read as well

If you're trying to capture your job configuration, you don't want your build history (due to large size), and you want the configuration for an off-site test setup... then you can tar up your Jenkins home without capturing the build metadata.

Thanks and you're welcome. I am considering adding on how to package apps that have shared library dependencies using ldd utility (apps that aren't statically compiled). A few examples of that: - https://github.com/PeterDaveHello/docker-shellcheck/pull/11 - https://github.com/samrocketman/blog/issues/81 - https://github.com/samrocketman/docker-webhookrelay/blob/main/Dockerfile

Here is my guide to production Docker images which includes practical examples. Also, if you think you still need a shell in your minimal container here’s an example of reusing busybox from Alpine.

If you don't want to use git to capture your Jenkins home data, here's a tar command method