Enable cd workflow

[justusbunsi]

To reduce manual overhead on releases, this can be automated.

[justusbunsi]

Referring to these docs: https://www.jenkins.io/doc/developer/publishing/releasing-cd/

[lafriks]

I was wondering if there is really no way to release version only on tag and with tag number 🤔

[lafriks]

I think you are missing .github/workflows/cd.yaml - template: https://github.com/jenkinsci/.github/blob/master/workflow-templates/cd.yaml

Maybe this template could be tuned to publish only tags and with tag as plugin version?

[justusbunsi]

I think you are missing .github/workflows/cd.yaml - template: https://github.com/jenkinsci/.github/blob/master/workflow-templates/cd.yaml

Maybe this template could be tuned to publish only tags and with tag as plugin version?

😆 Had this locally and didn't noticed that it somehow got ignored from being added.

[justusbunsi]

Wouldn't the current workflow template create a tag and release on behalf due to "Release drafter"?

EDIT: Based on the referenced docs it is possible to exclude at least on-push releases.

If you prefer to only deploy explicitly, not on every push, just comment out the check_run section in the workflow.

So I guess it would also be possible to run this workflow only on tag creation.

[lafriks]

Oh, you are right, it will create tag/release from workflow 😞

I would prefer not to release on every merged PR but manually

[lafriks]

We still need to define secrets for Maven/Artifactory before merging

[justusbunsi]

We still need to define secrets for Maven/Artifactory before merging

This should be added automatically since the infra PR got merged.

[lafriks]

yes, you are right, in fact they already are

[justusbunsi]

Oh, you are right, it will create tag/release from workflow 😞

I would prefer not to release on every merged PR but manually

I'm not 100% sure if this really is the case. Regarding the docs there are some labels indicating merges "of interest". As long as there is none of these, the main branch doesn't get released. Maybe I am missing something.
Let's investigate the behaviour and adjust this PR according to our needs before merging. Maybe we can configure more than we see right now.

[lafriks]

I still would prefer to use this part ;)

[justusbunsi]

Do we keep the versioning as if it would be fully automated?

[lafriks]

Yes, I don't think there is other option, imho. If there is maybe it can be somehow done using workflow inputs to specify version number: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

[justusbunsi]

If there is maybe it can be somehow done using workflow inputs to specify version number: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

This works pretty well. Have used it a few times. But not with Java projects.

EDIT: Referring to https://www.jenkins.io/doc/developer/publishing/releasing-cd/#pom-file-modifications, there are different versioning strategies. I've picked the first but we could do releases with Gitea patches in an automated way using the workflow dispatch feature.

[lafriks]

that acutaly sounds good

[justusbunsi]

You mean changing the versioning strategy or release with Gitea patches? Or both? 😀

[lafriks]

I mean manually changing version and than manually triggering release workflow

[lafriks]

We can still manually manage this part:

[justusbunsi]

@lafriks Apologies for the delayed response. 🙂 Concluding all the comments above it seems that we want to manually create tag and then have the GitHub actions automatically craft a release based on that tag and automatically create a changelog using release-drafter.

We would have two options regarding version value in pom.xml. Not sure if any of both has disadvantage over the other one:

• Keep a placeholder and not update the version upon a release and just use the tag name during release build as version value
• Manually bump the version before tagging

---

Does this sums it up? If so, I'll modify the scripts according to that.

[justusbunsi]

@lafriks Hrm... I struggle to understand how the described behavior can be integrated into the current workflow without knowing how exactly it behaves. How about first see the current release in action before changing the automation? There won't be automatic releases since the workflow only reacts to dispatch events, so we have full control over it right now.

As discussed above, I've changed the pom.xml to use the second approach from the docs but also dropped the maven.config change regarding changelist format. So it should result in a proper 1.4.0. Maybe the tag name will differ from the others.

If this is ok for you, then let's find out what happens. 🙈

[lafriks]

Ok, let's see what happens :)