dependabot[bot] on npm_and_yarn
Bump path-parse from 1.0.6 to 1… (compare)
dependabot[bot] on maven
Bump httpclient from 4.5.10 to … (compare)
@halkeye:g4v.dev Oh understood, so 2 lts is anyday preferable by users, 1lts in some cases.
I was thinking to give an option to users to select Jenkins Version at the beginning when they enter the site (to make it more customizable for them), and accordingly fetch supported plugins for the chosen Jenkins version.
What I have tried:
1.) append "?version=<jenkins.version entered by user here>" to the default update center site.
2.) Then I thought about individually getting plugins from their own pages, and this is what the above-shared image is about, I was thinking of fetching a plugin if 'the entered jenkins version' is present in its own page (as shown for "additional-metrics", it is supported by 2.150.2)
Bigger question is, would jenkins users like to select the jenkins version of their choice? Or they'd always like to go with recommended version?
@dheerajodha: as someone who runs the latest weekly with latest plugins your going to get just a confirmation of your own theories.
I don't think it's worth spending time with it until users ask for it. Surveying and figuring out users behavior is an entire job/discipline in itself.
mvn release:prepare release:performcause so far its only me that has done the release, and I want to make sure the whole process works end to end. I mean it can be @kwhetstone or someone else with write access too
What do we think about letting a user configure each plugin right from the UI of this project?
For example, for Git Plugin, when the user clicks on its "Add to Configuration" card, a modal (say) will ask them to enter:
Does it sound like a beneficial feature to have?
Hello everyone, I have made some changes according to the feedback I got previously, so please have a look at my proposal and share your thoughts on the new changes, thank you!!
Yesterday I read and followed multiple blogs on how we can use JCasC to configure the Jenkins server.
I was able to install plugins, set Jenkins URL, created a new user, and set up authorization by updating my jcasc.yaml file and tested all of them by running an updated Jenkins docker image.
Now that I think about it, correct me if I'm wrong, so we can get the user to set up the jcasc.yaml file right on this service and update the corresponding docker image along with it, and at the end, just like Wiki exporter, they can be shipped to the user via a ZIP file, which they can extract, and then build, run the docker image to see their configured Jenkins server (as mentioned above).
Now I was thinking, why would anyone like to use this service to write jcasc.yaml file to configure their Jenkins? How are we making this process easier? Because there are lots of APIs to remember for a user, how do we make it possible for them to write jcasc.yaml file with fewer efforts? Correct me if I'm wrong, but let's say the user wants to set up an authorization strategy, I believe this can be done in 2 ways:
So, how is 2nd approach different from 1st one, it's also a long boring UI that user needs to go through in order to configure their jcasc.yaml file, which in turn will configure their Jenkins? Apologies if this is a naive question.
Yes, #2 is definitely a lot of work, I wrote it because I was trying to explore whether if it's possible to help users to make a casc file right here on this project very easily or not.
Because as suggested before "I would say generate a zip file like we did for the wiki exporter. IT can have the jar, jcasc.yaml, and a Dockerfile", I thought in that direction @halkeye:g4v.dev