Create build for jenkinsci/winp on release ci server

[slide]

Service(s)

release.ci.jenkins.io

Summary

In order to sign the DLL's that will be built as part of the WinP build, the build for releases will need to be done on release.ci.jenkins.io which has access to the code signing cert (also used in the MSI code signing during weekly/LTS releases).

The build setup on the release server should publish the maven artifacts after the build is complete. The signing env should be setup the same was as is setup for the MSI build (the names of the env variables, etc).

We would want to disable publishing of Maven artifacts from the ci.jenkins.io CI path as well. Not sure if that is possible right now.

cc: @MarkEWaite @oleg-nenashev

Reproduction steps

No response

[timja]

This is fine with me.

The pod template used for Jenkins core is:
https://github.com/jenkins-infra/release/blob/master/PodTemplates.d/package-windows.yaml

I'd suggest something like that gets added to the winp repository and another Jenkinsfile something like:
Jenkinsfile_release

Then it will need adding to release.ci here:
https://github.com/jenkins-infra/kubernetes-management/blob/main/config/jenkins_release.ci.jenkins.io.yaml#L288

[dduportal]

cc @timja as release lead: I'm ok with this on the infra side, but I want a second point of view.

In term of implementation on infra side, we'll need to:

• Add Linux Agent template identical to ci.jenkins.io
• Add a job in release.ci.jenkins.io (JobDSL)
• Run a first build setup without publication but with signing to verify everything looks good
• Work on the deployment part

Note: the security of this job will be vital:

• No PR build at all
• No GitHub checks or any kind of feedback notification

[dduportal]

@slide what is the expected release process?

• Triggered by a tag pushed on the system?
• Schedule based (like Jenkins)?
• A human trigger the release build on release.ci on request ?
• Other trigger ?

[dduportal]

This is fine with me.

The pod template used for Jenkins core is: https://github.com/jenkins-infra/release/blob/master/PodTemplates.d/package-windows.yaml

I'd suggest something like that gets added to the winp repository and another Jenkinsfile something like: Jenkinsfile_release

Then it will need adding to release.ci here: https://github.com/jenkins-infra/kubernetes-management/blob/main/config/jenkins_release.ci.jenkins.io.yaml#L288

For the record, the Jenkins Infra team would prefer to use an Azure Windows VM rather than a Windows pod template:

• Agent availability time is way better (2 to 5 min instead of 16 to 20 min)
• Tooling would be exactly the same as ci.jenkins.io

[slide]

I am not one of the main maintainers of WinP (right now), so I may need to defer to someone else in terms of when we should trigger the release. Let me do some digging on that.

[timja]

no one is actively maintaining it as far as I know. people in jenkinsci/core have been rarely releasing it as required.

[slide]

Ok, I'll request to become a maintainer for it then. Do you have a recommendation for a trigger? I don't think the component is changed frequently, so having a human based trigger would probably be fine?

[timja]

Ok, I'll request to become a maintainer for it then. Do you have a recommendation for a trigger? I don't think the component is changed frequently, so having a human based trigger would probably be fine?

Simplest is probably on tag?

Nicest would be to run on main and create the tag if there's interesting changes.

[timja]

See also @basil's suggestions in jenkinsci/winp#117