jenkinsci/jenkins-custom-distribution-service

halkeye

@halkeye:g4v.dev

my guess is version of the plugin - https://plugins.jenkins.io/additional-metrics/#releases

especially since the directory is called pluginversions

Dheeraj

@dheerajodha

Thanks for your reply:)
yes, makes sense, I was also wondering what does this "8" in the attached pic means corresponding to the Jenkins version "2.150.2" and plugin version "1.2"?

2 replies

halkeye

@halkeye:g4v.dev

[m]

i wouldn't use any of that data as absolutes. You can't tell what people have installed, but some jenkins installs have opted to report back with information. THat woulds say in a given month 8 installs using jenkins 2.150.2 and additional-metrics version 1.2 have reported in

Dheeraj

@dheerajodha

This clears my doubt, and yes if the installs info is not accurate all the time so it makes sense to not rely on it completely :thumbsup:

halkeye

@halkeye:g4v.dev

[m]

@dheerajodha: I can't imagine many users are going to build a new distribution for really old installs. They either update often, or they rarely update and don't use new features. for custom distribution site, i wouldn't go back further than 2 lts, I personally would only do 1 lts until someone complains

Dheeraj

@dheerajodha

@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.

But this still contains plugins not supported by the entered jenkins version.

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)

This definitely is very bad approach to fetch supported plugins, in terms of time and space.

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?

halkeye

@halkeye:g4v.dev

[m]

@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.

So far my involvement in this project has been mostly ops focused, a bit of JavaScript and very little day to day planning.

I think Oleg and Kristin were the mentors for this project and might have a better idea. @kwhetstone

Kristin Whetstone

@kwhetstone

I would start selecting the jenkins version as the latest and the latest lts. I'd imagine the main users of the tool are using this to get their first bundle/starting from scratch

So if they're starting essentially as a new Jenkins install, let's get them on the latest version. All those security updates :)

Dheeraj

@dheerajodha

That's great! Thanks a lot for your inputs @halkeye:g4v.dev and @kwhetstone :D

halkeye

@halkeye:g4v.dev

[m]

@sladyn98: i realy really want you to do mvn release:prepare release:perform cause 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

1 reply

Dheeraj

@dheerajodha

Hello! Here's my first draft proposal for GSoC 2021, project name is "Custom Jenkins Distribution Service Improvements"
Link for the proposal: https://docs.google.com/document/d/1OHmmLDu3AjqqB3nHwPgpeYqRCJowYnDE_LLN0EGUsRU/edit#
Thank you for your time :)

1 reply

Kristin Whetstone

@kwhetstone

@halkeye I can try running it if I still have write access. I had some weirdness going on with my Jenkins account so I might have to get that sorted first.

1 reply

Dheeraj

@dheerajodha

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:

Repository URL
Credentials
Name
Refspec

Does it sound like a beneficial feature to have?

halkeye

@halkeye:g4v.dev

[m]

What would doing that get them?

Sladyn

@sladyn98

That would allow them to be able to configure the individual plugins from the web ui/locally itself right

Dheeraj

@dheerajodha

yes, that is exactly what was on my mind as well! lmk if that sounds good

halkeye

@halkeye:g4v.dev

[m]

yea but what will it do? will it setup a new job that has that repo? Would you handle each plugin individually?

1 reply

Kristin Whetstone

@kwhetstone

I though the more important thing to work on for this proposal is to support being able to run this as a utility locally

Sladyn

@sladyn98

Yeah that is the most important thing, we need to get this project working locally :+1:

You could try running the project locally and note its shortcomings in the proposal

That would give you a fair idea of what needs to be done to fix it

I have provided some feedback on the excellent start

Dheeraj

@dheerajodha

okay, understood :thumbsup: thank you:D

Dheeraj

@dheerajodha

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!!

Link: https://docs.google.com/document/d/1OHmmLDu3AjqqB3nHwPgpeYqRCJowYnDE_LLN0EGUsRU/edit#

Kristin Whetstone

@kwhetstone

Thanks @dheerajodha for sharing the proposal here. @sladyn98 can you also help review?

@dheerajodha if you have any questions about the application, feel free to ask. Also, there's several tasks created within the project repo if you would like to become familiar with the project before the application period.

Dheeraj

@dheerajodha

Yes, @kwhetstone thanks a lot, I'll check the created tasks within the repo.

Dheeraj

@dheerajodha

I have been meaning to solve some more open issues but for the past few days proposal writing kept me busy, so there are some issues I'm very interested to solve after 13th April, so should I add them to my list of "Miscellaneous Tasks" in my proposals or should I not add them?

Dheeraj

@dheerajodha

Plus, can we use Custom WAR Packager to build docker images based on the YAML config files? If it's possible, does that seem like a good idea to explore?

Kristin Whetstone

@kwhetstone

@dheerajodha I think it would be more interesting to generate the yaml for CasC. Someone might want a docker image, so it'd be an interesting alternative format in which to publish your stuff

halkeye

@halkeye:g4v.dev

[m]

it would be very hard to ship docker images for other people, I would say generate a zip file like we did for the wiki exporter. IT can have the jar, jcasc.yaml, and a Dockerfile

3 replies

Kristin Whetstone

@kwhetstone

Sladyn

@sladyn98

This is a great suggestion

Generating a casc file is not trivial though

I had this insane idea last year where we would run the jenkins war inside a docker container and use the export to get the jcasc file

Dheeraj

@dheerajodha

Thanks a lot for your inputs, really helpful! I read multiple blogs in the meantime to further understand how yaml -> CasC can be achieved, I can totally see how having this functionality can make this service so much better, I'll definitely start researching on it from now onwards.

Dheeraj

@dheerajodha

Hello!
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:

The usual way, via the Jenkins UI.
The JCasC way, using this service (which is what the plan is about). So, in order for a naive user to not actually type the jcasc.yaml file by themselves (that's the goal right?), we'd give them options on the web UI about which strategy they'd like (unsecured, legacy, etc) and according to their response we'll update the jcasc.yaml file.

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.

halkeye

@halkeye:g4v.dev

[m]

I think #2 is a billion times more work than #1 that already exists and has all the data and UI to make it easy.

Then again I'm not sure what the advantage is for this tool vs war + plugins (I only showed up to help get it deployed)

Kristin Whetstone

@kwhetstone

@dheerajodha I think that you're asking if a goal of this tool is to eventually export the casc yaml file? Yes, @sladyn98 did some research for that and found it was very difficult. However, I think that this would be something very useful since a lot of people use casc. I'm not sure if there's any effort to do this type of automatic generation in the casc project... there's a gitter channel for that I haven't looked at in awhile.

Gavin's right, the casc is incredibly hard. There's a lot of variables at play for a casc project. It wouldn't hurt to look at it and do some discovery to see what happens.

Dheeraj

@dheerajodha

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

Dheeraj

@dheerajodha

@kwhetstone Yes, exactly, because as suggested by you previously to generate a yaml for CasC, I started thinking about how we can automate this JCasC yaml making process right from this project (if that's what you meant, please correct me if I'm wrong).
I agree, so I think there's JCasC office hours coming in few days, if it is still on I will try to ask about this there or def its Gitter channel.

Kristin Whetstone

@kwhetstone

@dheerajodha going to the office hours would be a great way to find out what problems would be best solved in that project

Great idea!

Dheeraj

@dheerajodha

Sure @kwhetstone, thank you!

Where communities thrive

People

Repo info

Activity