Support CD workflow on Windows

[pbo-linaro]

Service(s)

ci.jenkins.io

Summary

In the context of the winp component, we are trying to enable CD workflow as expected (see this issue).

This component can be built only under windows, so maven cd part should be done from this OS as well.

The different hints given on the issue are mostly "Try that, I won't do it", so it's a bit hard for me to figure what is the correct step and expected work. Especially, as an external contributor, it's hard to justify spending time modify jenkins internal actions scripts associated to this, as our original work, was simply to support a new architecture (windows-arm64).

Would that be possible to support signing/cd on Windows through a reusable workflow?

If it's too complicated, maybe we could support doing the build only on Windows, export artifact to a linux job to get this signed and published.

Your team has been very helpful on #4047, so I hope more help can be given here. I'm not sure of the right service for this issue, feel free to change it.

Thanks,
Pierrick

Reproduction steps

No response

[basil]

This ticket has been prematurely filed, as the expectation is for the contributor (and not the infrastructure team) to write or modify any GitHub Actions based CD workflows, reaching out to the infrastructure team only if a certificate is needed.

[pbo-linaro]

Please let the infra team decides if it's up to them to do this or not. Thanks.

[basil]

Unfortunately getting new native winp binaries built, signed, and released will require more than simply filing tickets or asking others to do various tasks. I have given you guidance on the next steps in the other ticket, and I want to make it clear to the infrastructure team that we are not asking them to go outside of the bounds of their normal responsibilities.

[pbo-linaro]

As you mentioned in "jenkinsci/winp#117 (comment)", I'm also not a member of the infrastructure team, so please stop defining bounds of what you're not part of. Thanks.

I feel like it's not normal to ask an external contributor to understand and fix all the things mentioned, and I would appreciate the feedback of a member of the infra team on that.

Finally, finding a correct way to sign and publish a release for a jenkins component (in a new case) definitely falls into range of this team here. If not, I really wonder who could do it.

[basil]

I haven't closed this ticket, so I am definitely not acting unilaterally on behalf of the infrastructure team. Regarding whether it is normal to ask a first-time contributor to pay off existing technical debt of this magnitude, I agree that it ideally wouldn't be required in a perfect world. In a well-maintained Jenkins core component or Jenkins plugin, a new feature could simply be reviewed, accepted, and released by a responsive maintainer in a timely fashion without any additional effort. Unfortunately, this is far from the reality in much of the Jenkins ecosystem today (although it is slowly getting better — I have personally dedicated an enormous amount of time to revitalizing this ecosystem and leaving things in a better state than I have found them).

The unfortunate reality is that this component was abandoned in an unreleasable state by its previous maintainer(s), so it needs to be brought back to life by someone. Another unfortunate reality is that over the past few years, no maintainer has stepped up to modernize this component, and its native portions remain unreleasable to this day. This is an open source project, so tasks are performed by volunteers who choose to work on them — there is no way to compel someone to work on a given task (although you have made several attempts to do so). As a result, technical debt like this often piles up until it has to be done in order to proceed with some unrelated feature, at which point paying off the debt is neither easy nor pleasant.

While this may not be as common in younger open-source projects or in corporate environments, Jenkins is a pretty old open-source project and some parts of it have stagnated over the years. It is common for new contributors to Jenkins to have to first "modernize" a plugin before releasing their feature — so common, in fact, that we have a whole tutorial for it. Modernizing winp is a bit of a unique case, so we don't have a specific tutorial for that, but my basic point is that it is normal for us to ask new contributors to do this type of work. Of course, it is challenging and often thankless, which is why I have attempted to provide you step-by-step instructions in the other thread, as well as timely reviews.

Naturally, the long-term solution to this problem is to pay off the debt and to not allow components to become abandoned in the first place. I am suggesting that we solve the signing problem using automation. In this way, we won't fall into this trap again in the future.

With regard to the infrastructure team, I will let them speak for themselves, as they certainly have experience managing a wide variety of signing mechanisms for the Jenkins project. Historically, though, their involvement has been focused on managing the certificates themselves; in contrast, developers have historically focused on writing the Maven based build scripts and GitHub Actions based CD workflows in use today. Of course, this doesn't preclude the infrastructure team from getting involved in a new area in the future, but it does inform a set of expectations based on past precedent.

[dduportal]

Hi folks, given the current "banking day chaos" in Europe this month of May, the Jenkins infra team has limited availabilities.

As such, we'll discuss this issue middle-end of May to see how to move forward.

As per @basil comments, the infrastructure team is usually providing the certificates and delegating to developers/maintainers the work on the Jenkins pipeline libraries or reusable GH actions.
Depending on the infrastructure contributors willingness and availability we can do a bit more than the usual: but it is not the case nowadays as we have much topics to tackle which are way more important.

Automation is clearly a great way to tackle this problem and I tend to agree with @basil : my task list maps his task list (at least after a quick analysis and based on our experience on signing Jenkins Core MSI installer and contributing to the current Linux CD actions).

Especially, as an external contributor, it's hard to justify spending time modify jenkins internal actions scripts associated to this, as our original work, was simply to support a new architecture (windows-arm64).

I'm not sure to understand the reasoning here: either you need the new architecture to be delivered or not. If the allocated time cannot be justified then is it worth supporting the new architecture? If there are users / customers I'm not sure to understand why it is not justified?

We understand the frustration of not being able to have a short feedback loop but as stated by @basil the project is old and this component was not maintained on the past years. We are sorry for that but except fixing the problem all together there are no other way going forward.

=> Let's discuss the topic during the next infra team meeting. You are welcome to join (Every Tuesday at 14h00 UTC, we can add the subject 30-45 min later in the meeting to meet your timezone).

[pbo-linaro]

Thanks for your answer @dduportal.
I think we all agree on the fact that automation is the best solution here, the problem is just to know who will spend time making it automated.
In our case, we have other projects and priorities for now, that prevent us to focus on that, compared to windows-arm64 enablement work.

I would like to add that winp libraries are loaded on every windows system running jenkins, and since it's one of the only native component (only found jansi else), it would make sense to have it properly maintained, by the core team. It's probably one of the best attack vector for someone who would target jenkins.

All that said, I won't be available for infra meeting tomorrow, but you're welcome to share the conclusion of discussion here.

Thanks,
Pierrick

[basil]

Thanks Pierrick! If and when you (or anyone else who is interested) steps up to work on this task, we would be very grateful for the contribution.