feat: add publish for custom version

[kgwizdz-splunk]

Background

In certain scenarios, some clients prefer not to update to the latest version of the software but require critical bug fixes in their current version. This necessitates bypassing the automated versioning provided by semantic-release, allowing for a manually specified version to be released.

Changes Introduced

In this PR, I've introduced a dispatcher to the workflow, enabling users to specify a custom version when triggering a release. This enhancement provides greater flexibility, particularly for clients who need targeted updates without adopting the latest release.

Key Implementations:

• Custom-Version Dispatcher: Added a dispatcher that allows users to input a custom version number when initiating a release. This ensures that specific bug fixes can be released independently of the standard semantic-release process.
• Release Workflow: Integrated the release process with softprops/action-gh-release@v2, ensuring a smooth and consistent release experience while accommodating the custom version specified by the user.

Discussion Point:

Tag Creation and Workflow Rerun: Currently, when a custom version is used and a package is released, the workflow is triggered again because a tag is created. This raises the question: Is it necessary to trigger the workflow with a tag, or should we consider an alternative approach to prevent redundant workflow executions? Feedback on this point would be appreciated.

Test branch:

https://github.com/splunk/splunk-add-on-for-microsoft-cloud-services/actions/runs/10353886295

References

Implementation docs: https://docs.google.com/document/d/1Qenm338CyoeZHo3M_dbX5GJD1SDmlLhz1Jfpg7VWrPg/edit
GitHub Action: softprops/action-gh-release@v2

[mkolasinski-splunk]

Could you please have a look at: https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases

Maybe that would fit your needs and would not require that many changes in reusable workflow?

[mkolasinski-splunk]

Consider adding additional restriction to run appinspect-api only for github event pull_request so we can limit a bit amount of appinspect-api executions (observed in past problems with scans when appinspect api was overused)

[awownysz-splunk]

Done - used base_ref instead of ref_name for develop branch

[mkolasinski-splunk]

I think you need to include in second group of OR conditions !cancelled() && needs.pre-publish.result == 'success'

[awownysz-splunk]

Resolved

[mkolasinski-splunk]

Could we rather rely on some output of step Release custom version?

[awownysz-splunk]

Resolved - now checking if upload_url output exists for the custom release step

[awownysz-splunk]

Could you please have a look at: https://semantic-release.gitbook.io/semantic-release/recipes/release-workflow/maintenance-releases

Maybe that would fit your needs and would not require that many changes in reusable workflow?

@mkolasinski-splunk we've already considered this option before, however this won't fully fit our needs. This functionality from semantic-release has certain strict rules (e.g. naming convention for branches, commits, etc.), and we need a bit more flexibility when doing custom releases. Hence we decided to go for softprops/action-gh-release@v2

[awownysz-splunk]

Latest updates

I took over the PR from Kamil and introduced 2 important changes:

• added validate-custom-version job which validates the string provided in the custom-version input
• added run-all-tests-on-develop input which allows for running full suite of workflow jobs also on develop - this functionality is needed for our new branching strategy. The input has a default value of false - thus it won't introduce any change for other TAs, unless true value is explicitly provided.

Testing done

• Workflow triggered manually, invalid custom version string (test) provided in the workflow dispatcher - validation job failed with relevant error message; build, tests and publish jobs not executed: workflow url
• Workflow triggered manually, valid custom version string (1.2.2) provided in the workflow dispatcher - validation job passed; build, tests, and publish jobs executed; release created properly: workflow url, release url
• Workflow triggered on PR to develop with run-all-tests-on-develop input explicitly set to true - validation job skipped; full suite of checks and tests executed: PR url, workflow url
• Workflow triggered on PR to develop without providing run-all-tests-on-develop input - validation job skipped; standard behaviour, limited suite of checks and tests executed: PR url, workflow url
• Workflow triggered on PR to main - validation job skipped; standard behaviour, full suite of checks and tests executed: PR url, workflow url

[awownysz-splunk]

Latest updates v2

As per discussion with @mkolasinski-splunk and @wtobis-splunk, I updated the PR as follows:

• limited the triggers for tests on develop branch to push events only (run-all-tests-on-develop -> execute-tests-on-push-to-develop - PRs have been excluded to limit the amount of full workflow runs
• added option to run tests on release branches, works the same way as the option for develop - new workflow input (execute-tests-on-push-to-release) with default value of false, allows for running tests on push events, PRs are excluded
• also, enhanced validation job to check if the provided release version already exists - as per @kdoroszko-splunk suggestion

Testing done

Tests on push to develop

• Workflow triggered on push to develop, without providing execute-tests-on-push-to-develop input - commit url, workflow url -> Outcome: limited workflow run ✅
• Workflow triggered on push to develop, with execute-tests-on-push-to-develop input explicitly set to true - commit url, workflow url -> Outcome: full workflow run: ✅
• Workflow triggered on opening the PR (not a push event), with execute-tests-on-push-to-develop input explicitly set to true - PR url, [workflow url] (https://github.com/splunk/splunk-add-on-for-microsoft-cloud-services/actions/runs/10561246411) -> Outcome: limited workflow run ✅
• Workflow triggered on PR merge to develop (which is a push event), with execute-tests-on-push-to-develop input explicitly set to true - PR merge commit url, workflow url -> Outcome: full workflow run: ✅

Tests on push to release branch:

• Workflow triggered on push to release/..., without providing execute-tests-on-push-to-release input - commit url, workflow url -> Outcome: limited workflow run ✅
• Workflow triggered on push to release/..., with execute-tests-on-push-to-release input explicitly set to true - commit url, workflow url -> Outcome: full workflow run ✅

Validation of existing release version:

• Workflow triggered manually, custom version string for already existing release (1.2.2) provided - workflow url -> Outcome: validation job failed ✅

[mkolasinski-splunk]

There are pre-commit issues in CI that needs to be fixed.

[awownysz-splunk]

@mkolasinski-splunk linting issue fixed

[srv-rr-github-token]

🎉 This PR is included in version 4.17.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀