Jenkinsfile Runner roadmap - Discussion

Contributing Jenkinsfile Runner
1

Hi all, as a follow-up to the Oct 09 Jenkins Contributor Summit, I have created a draft roadmap for Jenkinsfile Runner as a project. It includes various key initiatives in terms of features, infrastructure, community, etc. It is implemented as GitHub project for now. I would appreciate feedback about the format and contents

Live roadmap

Screenshot

image
image2504×1248 336 KB

References

2

I have added a few extra items based on feedback I have got from @shadycuz and a few other folks. Contributions are welcome!

3

Hi, I went through the items in Jenkinsfile Runner Roadmap (Preview) · GitHub and have a few highlights

A) Mission definition

I miss the overall mission definition. Having the final goal described helps to have a discussion around the means to get to it.

Plus it can help to prioritize key efforts and to triage all the various ideas / enhancement proposals etc.

I know there is GitHub - jenkinsci/jenkinsfile-runner: A command line tool to run Jenkinsfile as a function section. To mee it feels too high level, I would like to see a more detailed description of use-cases so that people coming to the project can get quick info about where to use it, what it can help with etc.

B) Target environments

Roadmap mentions enhancements around custom war creation, Tekton integration, Docker enhancements, GitHub actions support, JBang support.

A bit connected with the above point, the definition of must have + optional target environments for 1.0 release could help to keep the right focus.

Related to “make JFR accessible for non-Java users”, JReleaser could be reviewed, it has support for various distribution packages - Binary :: JReleaser

C) Fast and easy to use

Work with JFR feels a bit heavy-weight, at least the initial setup of Jenkins war + plugins when the Docker image is not used.

Demo in GitHub - jenkinsci/jenkinsfile-runner: A command line tool to run Jenkinsfile as a function requires to build an image locally before running it, expects make friendly attitude of the users.

Newcomer experience isn’t “run and see”, but it’s “start the build, wait, run and see”. This should be imho improved.

This section is not just about the initial experience. Especially with FaaS context, there needs to be a push towards boot and runtime efficiency.

It can be handled in various aspects, starting with Jenkins related optimizations (slimmed down Jenkins?), prepackaging stuff like plugins, packaging into native binary.

Also depends if FaaS context gets prioritized in the mission definition for 1.0 release.

D) all in one bundle

To have a better user experience I would appreciate bundle(s) which I could just download (.zip, docker, .dmg?, .exe?) and use with my jenkins file without the need to create it on my own. I think Image packs for standard toolchains · Issue #573 · jenkinsci/jenkinsfile-runner · GitHub goes this way, but for a good user experience, these packs should be available directly without the need to build them. it can be questioned for 1.0 release but wanted to mention this, especially with user experience in mind.

E) Timeline for roadmap goals

I miss information about the time frame for the items tracked in the roadmap.

Is 1.0 release going to be time-boxed or feature-boxed?

F) Java 17+ only?

This may be too optimistic, but why not base JFR on Java 17. This could be a good excuse to perform some codebase cleanup and it could attract people as the project would look modern / future-looking, and not stuck on Java 8.

Jenkins was mentioned in The arrival of java 17! – Inside.java as 17 early access builds participant :wink:

1 Like
4

A) Mission definition

Agreed, an explicit manifesto is needed. Created Jenkinsfile Runner manifesto · Issue #579 · jenkinsci/jenkinsfile-runner · GitHub

Basically I want Jenkinsfile runner to be a way to run Jenkins jobs in a portable way so that they do not require a constantly running Jenkins controller. We could briefly call it “Jenkins Anywhere: from your local computer to any SaaS”

Target environments

Generally I would like to see Jenkinsfile Runner to be usable anywhere. In particular, all container environments and hosts that can run a JVM. Native images is rather wishful thinking at the moment, it is challenging for Jenkins Pipeline

C) Fast and easy to use

Demo recording needs to be replaced once Docker images CD flow is redeployed. Many demos document running HFR in a container, but indeed a choice of GIF is not good for this matter

D) all in one bundle

Agreed regarding image packs. Yes, they will be available as Docker images too

E) Timeline for roadmap goals

I deliberately do not want to commit on any timeline in the roadmap. JFR is an open source project without major enterprise backing or commercial support at the moment. As volunteer, I do not want to make time commitments. Especially now when my personal time is stretched.

The Jenkins roadmap is the same FTR, see Jenkins JEP-14

  • We do not provide any target dates. Instead of that we provide 3 horizons: “Current”, “Near Term” and “Future”
  • We do NOT commit on initiative delivery. Jenkins is a community-driven project, and the change will happen in areas where we have contributions. Initiatives in the roadmap may stop.

Is 1.0 release going to be time-boxed or feature-boxed?

The latter. Basically I want to see several sizeable adoptions before 1.0 that would confirm that all major requirements are in place. No hurry with the 1.0 release

F) Java 17+ only?

Might be. I would consider dropping Java 8 once Java 17 is fully supported in Jenkins

5

New pull request for the roadmap publishing: Publish Jenkinsfile Runner roadmap by oleg-nenashev · Pull Request #583 · jenkinsci/jenkinsfile-runner · GitHub

I also added a few more issues based on consideration:

6

My next feature for DSTY - JSL is almost ready and then I will be spending some time trying to get a beginner friendly example PR submitted based on the Jenkins community docker hub image.

That should help with the Fast and easy to use.

1 Like