I’ve had this project idea for a few months now, but I haven’t been able to implement it yet, because of time constraints.
Each time I want to submit a PR to jenkins.io, be it for a blog post or a documentation update, I have to build the website on my machine (WSL2).
It works of course, but it does not have all the checks that the Jenkins workflow has.
I tried to add my jenkins.io github repo fork in my Jenkins controller, but… some plugins are missing, and the log files don’t tell me which.
My idea is then to propose a docker-compose.yml file in the existing repo which would define a Jenkins controller with the right plugins and a Jenkins agent so that anybody having docker could then launch a build on his own instance whatever the host may be… and without waiting for the official deployment environment to kick in to build the PR…
This way, we would (maybe) have cleaner PRs to begin with.
I’ve already created a docker-compose.yml file for another project using JCasc, and it works quite well.
Sounds like a good idea, @poddingue, as far as I understand it.
I just want to understand/clarify what you understand as jenkins.io. Is it the static web site? Is it the build infrastructure?
Note that there are three easy ways to validate a Jenkins.io (static website) PR:
start a local jenkins.io instance with the make run command in the root directory of the local clone. It uses a dockerized environment. And it monitors file changes to reload the web site.
use the automatically created test environment that is linked to every PR (even draft). It is updated only at every commit on the work branch.
use gitpod to have a powerful environment equivalent to the first option. This is especially handy if the local machine doesn’t have the required “umpf” or doesn’ t like docker.
This said, the second paragraph has a lot of potential if I read correctly between the lines. Definitely worth digging.
From what I understood make run generates the static website, and serves it through a web server while rebuilding as soon as we modify something.
What I’m aiming for is something that mimics what happens when someone creates a pull request, i.e. run the pipeline described in Jenkinsfile.
There are some more checks that don’t happen with the make run if I’m not mistaken.
My proposal is not against the use of GitPod, as I wrote:
a build on his own instance whatever the host may be
The host could also be GitPod (or Vagrant, or…) … And we may switch from the existing Dockerfile to a revamp of my docker-compose.yml (or any other that does the same in a better way, this one was heavily guided by @dduportal).
I have opened a bug report regarding what’s missing in the Makefile compared to the Jenkinsfile.
If the community confirms this can be considered as bug, a discrepancy or whatever, then my proposal for GSoC 2023 does not make sense anymore (if it ever made sense ).
Now, that leads to another idea still linked to docker-compose.
By the way, thanks to @dduportal for taking the time to discuss the transformation of the original idea into this new proposal with me today.
What if we had a set of examples to get people started with Jenkins thanks to Docker?
We could have a set of docker-compose files representing various types of Jenkins instances (simple Docker, Kubernetes, …).
These examples would be described in the documentation, and would also (and that’s the main point) be tested every week thanks to ci.jenkins.io so that we know they are still working.
As the documentation is using asciidoc we could use the Include Content by URI | Asciidoctor Docs to have an up to date documentation when it comes to code snippets and at the same time, have ci.jenkins.io test these same code snippets.
Of course, these snippets could also be run thanks to GitPod.
@poddingue I was reading your discussion about the idea . How about making it in this way in the form of a complete system where everyone can run the Jenkins instances just by clicking so if someone wants the setup in their local machine , unless of doing it manually docker compose will automatically do the job for them which makes it easy for them to just start working on the project rather to first setting up the environment for that project .
).