This PR adds a simple docker example to the demo directory and closes #557.
I made the change to the project README.md in a separate commit so that is can easily be dropped or edited as the maintainers see fit. I just wanted to add the example, feel free to present it to users how ever you see fit.
I do think it's important to change how JFR is presented to users. There are several ways of running JFR currently.
You could run JFR locally by downlading/building the binary yourself.
You could run JFR locally by using the JFR docker image.
You could run JFR locally be turning the JFR docker image into a replica of the Jenkins you use in production.
You could run JFR locally by turning your production Jenkins docker image into a JFR.
I don't really think that the first 2 use cases will have lots of users. The third use case seems to be what most of the documentation in the Extending Docker section/readme is about and most of the demos. I think this is the reason I struggled to use this tool for so many years, because I was trying to turn my existing Jenkins image into a JFR and not turn the JFR into a copy of my existing Jenkins image.
Which is why I created this PR. I think the majority of users are wanting to take an existing Jenkins installation and make it run locally via CLI with JFR. I also think this will lower the burden on the JFR maintainers because JFR is actually kinda simple, at least compared to turning the JFR vanilla docker image into an exact replicate of each users Jenkins server. I think most of the issues and examples in the repo are about the Jenkins customization part because the documentation takes you down a path where you are turning the JFR docker image into Jenkins instead of the other way around.
My second point is that if you are going to start pushing the "convert Jenkins to a JFR" methodology. Then I highly recommend you standardize with the community Jenkins image. For example using the same file paths as they do for the war file, Jenkins home and plugins. Which I think can easily be done in #213 and would make it even easier for new users to get started with JFR and Docker. This also means all the customization of Jenkins would be pushed to the community Jenkins repo, which already is thoroughly documented and would allow for the JFR maintainers to worry about jdk versions, jbang etc and less about plugins, groovy init scripts and JCasC.
[x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
[x] Ensure that the pull request title represents the desired changelog entry
[x] Please describe what you did
[x] Link to relevant issues in GitHub or Jira
[x] Link to relevant pull requests, esp. upstream and downstream changes
[x] Ensure you have provided tests - that demonstrates feature works or fixes the issue
This PR adds a simple docker example to the
demodirectory and closes #557.I made the change to the project
README.mdin a separate commit so that is can easily be dropped or edited as the maintainers see fit. I just wanted to add the example, feel free to present it to users how ever you see fit.I do think it's important to change how JFR is presented to users. There are several ways of running JFR currently.
I don't really think that the first 2 use cases will have lots of users. The third use case seems to be what most of the documentation in the
Extending Dockersection/readme is about and most of the demos. I think this is the reason I struggled to use this tool for so many years, because I was trying to turn my existing Jenkins image into a JFR and not turn the JFR into a copy of my existing Jenkins image.Which is why I created this PR. I think the majority of users are wanting to take an existing Jenkins installation and make it run locally via CLI with JFR. I also think this will lower the burden on the JFR maintainers because JFR is actually kinda simple, at least compared to turning the JFR vanilla docker image into an exact replicate of each users Jenkins server. I think most of the issues and examples in the repo are about the Jenkins customization part because the documentation takes you down a path where you are turning the JFR docker image into Jenkins instead of the other way around.
My second point is that if you are going to start pushing the "convert Jenkins to a JFR" methodology. Then I highly recommend you standardize with the community Jenkins image. For example using the same file paths as they do for the war file, Jenkins home and plugins. Which I think can easily be done in #213 and would make it even easier for new users to get started with JFR and Docker. This also means all the customization of Jenkins would be pushed to the community Jenkins repo, which already is thoroughly documented and would allow for the JFR maintainers to worry about jdk versions, jbang etc and less about plugins, groovy init scripts and JCasC.
Ensure you have provided tests - that demonstrates feature works or fixes the issue