Enhance maven-cd.yml with an input to run job 'validate' only (job 'release' will be skipped)

[mhoffrog]

Motivation / Requirement

Currently the maven-cd.yml called by current cd.yaml will run a release, in case the Jenkins job build succeeded and there is at least one PR with a category of release interest. In case there is demand to combine more than one PR with an interesting category into same release, one has to disable check_run trigger in cd.yaml to manually trigger a cd run.

Currently the manual workflow_dispatch trigger will run the release job in any case and regardless of the PR categories just if last Jenkins build of the plugin did succeed.

Enhancement requirement

I would like to have the option to trigger a cd manually, but to perform the validate job of maven-cd.yml ONLY and to enforce skipping of the release job just to have a review and to check what PRs will get listed by release-drafter.
👉 If his PR gets merged, I would like to file another PR for the cd.yaml template to provide the validate_only input for workflow_dispatch.

Implementation Details

• maven-cd.yml:
  • add input validate_only with default to false
  • extend jobs.validate.outputs.should_release to ${{ inputs.validate_only == 'false' && ... }}
  • add step validate.steps.log-should_release-details to log details of the should_release flag to leverage analysis

Tests Performed

Test Case 1:

• backward compatibility to current cd.yaml template:
  • triggered with an unset (empty) input for validate_only
    => default 'false' effectively used
• s. https://github.com/jenkinsci/unleash-plugin/actions/runs/10655299938
  • step "Log should_release details" logs:

    ================================
    Release job filter details:
              VALIDATE_ONLY: false
                  CI_STATUS: success
       INTERESTING_CATEGORY: false
    --------------------------------
    =>       SHOULD_RELEASE: false
    ================================
    

  • => release is skipped only,
    since there is no interesting category

Test Case 2:

• cd.yaml extended to provide input validate_only to maven-cd.yaml usage:
  • see jenkinsci/unleash-plugin@5dae0eb
• s. action run https://github.com/jenkinsci/unleash-plugin/actions/runs/10656729271
  • step "Log should_release details" logs:

    ================================
    Release job filter details:
              VALIDATE_ONLY: true
                  CI_STATUS: success
       INTERESTING_CATEGORY: false
    --------------------------------
    =>       SHOULD_RELEASE: false
    ================================
    

  • => release is skipped,
    since VALIDATE_ONLY is true and there is no interesting category

Test Case 3:

• perform a manually triggerd release with validate_only NOT set
• s. action run https://github.com/jenkinsci/unleash-plugin/actions/runs/10656834727
  • step "Log should_release details" logs:

    ================================
    Release job filter details:
              VALIDATE_ONLY: false
                  CI_STATUS: success
       INTERESTING_CATEGORY: true
    --------------------------------
    =>       SHOULD_RELEASE: true
    ================================
    

  • => release is performed, since
    • VALIDATE_ONLY is NOT set
    • interesting category is true, since this action was triggered by 'workflow_dispatch'
  • s. release https://github.com/jenkinsci/unleash-plugin/releases/tag/91.v5da_e0eb_c1e01

@lemeurherve @timja - please have a look - thx Markus

[jglick]

just to have a review and to check what PRs will get listed

I am not sure I follow the use case. What do you get out of this that you do not get already by simply commenting out the check_run trigger? Even if the generated release after the manual trigger is not quite to your liking, you can simply edit it.

[mhoffrog]

just to have a review and to check what PRs will get listed

I am not sure I follow the use case. What do you get out of this that you do not get already by simply commenting out the check_run trigger? Even if the generated release after the manual trigger is not quite to your liking, you can simply edit it.

@jglick - Many thanks having had a look!
I know about the editing option of a release, but I don't want to edit things - I would just like to have a review on the release notes, what PRs would be included - just to check if the PR label marking is all correct and check what release-drafter is coming up with. Manually editing the release notes is not actually an option, since contributors are calculated and rendered by the release-drafter as well.
If I manually trigger with the current implementation I have only a single shot and the release is being done. I would like to have the option of something like a dryrun if I trigger manually.
This update does not affect any existing usage, it is fully backward compatible.

[mhoffrog]

If I manually trigger with the current implementation I have only a single shot and the release is being done. I would like to have the option of something like a dryrun if I trigger manually.
This update does not affect any existing usage, it is fully backward compatible.

@jglick Is there anything else I can help with to follow my use case?

[jglick]

I just have not had time to follow up, sorry. If anyone else (@timja, etc.) wishes to merge, go ahead.

[timja]

Can't you just add a separate release drafter workflow that runs on push / workflow_dispatch?
That would draft as you go and you can see and edit them easily and quickly.

(extracted from the workflow here:)

      - name: Release Drafter
        uses: release-drafter/release-drafter@3f0f87098bd6b5c5b9a36d49c41d998ea58f9348 # v6
        id: draft
        with:
          name: next
          tag: next
          version: next
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[mhoffrog]

@timja hmm - yes for sure I could have setup a dedicated workflow for this, but my considerations did have been

1. My extension might be a feature of interest for others as well
2. The logging of the detail conditions deciding on passing to a release or not - especially the check for labels of interest may help to follow the reason of this workflows behavior a bit more in case of wondering on why a release might not be performed
3. I did not want to do this just for my own to get the extension being part of the maintained infrastructure - otherwise I would have to take care on staying on track with probable changes of this or other infrastructure workflows

This was the reason to spend some time in well testing and documenting my test results to demonstrate full backward compatibility to the state being.
If you have further concerns on merging it for sure I have to accept it, but I would like to understand what and why - if you don't mind.

[timja]

Sure there's no harm in it let's go with it