feat: add publish for custom version #309

kgwizdz-splunk · 2024-08-12T14:46:47Z

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

.github/workflows/reusable-build-test-release.yml

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 · 2024-08-21T23:33:07Z

.github/workflows/reusable-build-test-release.yml

@@ -785,7 +811,7 @@ jobs:
    if: |
      !cancelled() &&
      needs.build.result == 'success' &&
-      ( github.base_ref == 'main' || github.ref_name == 'main' )
+      ( github.base_ref == 'main' || github.ref_name == 'main' || github.ref_name == 'develop')


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)

Done - used base_ref instead of ref_name for develop branch

mkolasinski-splunk · 2024-08-21T23:52:09Z

.github/workflows/reusable-build-test-release.yml

@@ -2086,9 +2113,12 @@ jobs:
          exit 1

  publish:
-    if: ${{ !cancelled() && needs.pre-publish.result == 'success' && github.event_name != 'pull_request' && github.event_name != 'schedule' }}
+    if: ${{ !cancelled() && needs.pre-publish.result == 'success' && github.event_name != 'pull_request' && github.event_name != 'schedule' || (github.event.inputs.custom-version != '' && needs.validate-custom-version.result == 'success') }}


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

mkolasinski-splunk · 2024-08-22T00:15:11Z

.github/workflows/reusable-build-test-release.yml

      - name: Download package-deployment
-        if: ${{ steps.semantic.outputs.new_release_published == 'true' }}
+        if: ${{ steps.semantic.outputs.new_release_published == 'true' || github.event.inputs.custom-version  != ''}}


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

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

awownysz-splunk · 2024-08-22T14:48:44Z

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 · 2024-08-22T15:41:28Z

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 · 2024-08-26T15:42:02Z

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.

.github/workflows/reusable-build-test-release.yml

awownysz-splunk · 2024-08-27T05:58:10Z

@mkolasinski-splunk linting issue fixed

srv-rr-github-token · 2024-09-03T13:44:20Z

🎉 This PR is included in version 4.17.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

kgwizdz-splunk requested a review from a team as a code owner August 12, 2024 14:46

kgwizdz-splunk requested review from wtobis-splunk and dkvashninsplunk August 13, 2024 06:28

kdoroszko-splunk reviewed Aug 13, 2024

View reviewed changes

.github/workflows/reusable-build-test-release.yml Show resolved Hide resolved

mkolasinski-splunk reviewed Aug 22, 2024

View reviewed changes

awownysz-splunk force-pushed the feat/add-custom-version-release branch from 8572827 to 2b87637 Compare August 22, 2024 13:34

awownysz-splunk requested review from mkolasinski-splunk and kdoroszko-splunk August 22, 2024 15:42

awownysz-splunk force-pushed the feat/add-custom-version-release branch from ddaddd5 to f0351d1 Compare August 26, 2024 14:53

mkolasinski-splunk reviewed Aug 26, 2024

View reviewed changes

.github/workflows/reusable-build-test-release.yml Show resolved Hide resolved

awownysz-splunk force-pushed the feat/add-custom-version-release branch from 0b75662 to 7f06ea7 Compare August 27, 2024 05:47

feat: add publish for custom version

efb57ff

awownysz-splunk force-pushed the feat/add-custom-version-release branch from 7f06ea7 to efb57ff Compare August 27, 2024 05:53

awownysz-splunk requested a review from mkolasinski-splunk August 27, 2024 05:58

mkolasinski-splunk approved these changes Aug 27, 2024

View reviewed changes

awownysz-splunk merged commit 8269f25 into develop Aug 27, 2024
6 checks passed

awownysz-splunk deleted the feat/add-custom-version-release branch August 27, 2024 07:54

github-actions bot locked and limited conversation to collaborators Aug 27, 2024

srv-rr-github-token added the released label Sep 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add publish for custom version #309

feat: add publish for custom version #309

kgwizdz-splunk commented Aug 12, 2024 •

edited

Loading

mkolasinski-splunk left a comment

mkolasinski-splunk Aug 21, 2024

awownysz-splunk Aug 22, 2024

mkolasinski-splunk Aug 21, 2024

awownysz-splunk Aug 22, 2024

mkolasinski-splunk Aug 22, 2024

awownysz-splunk Aug 22, 2024

awownysz-splunk commented Aug 22, 2024

awownysz-splunk commented Aug 22, 2024 •

edited

Loading

awownysz-splunk commented Aug 26, 2024

mkolasinski-splunk left a comment

awownysz-splunk commented Aug 27, 2024

srv-rr-github-token commented Sep 3, 2024

feat: add publish for custom version #309

feat: add publish for custom version #309

Conversation

kgwizdz-splunk commented Aug 12, 2024 • edited Loading

Background

Changes Introduced

Key Implementations:

Discussion Point:

Test branch:

References

mkolasinski-splunk left a comment

Choose a reason for hiding this comment

mkolasinski-splunk Aug 21, 2024

Choose a reason for hiding this comment

awownysz-splunk Aug 22, 2024

Choose a reason for hiding this comment

mkolasinski-splunk Aug 21, 2024

Choose a reason for hiding this comment

awownysz-splunk Aug 22, 2024

Choose a reason for hiding this comment

mkolasinski-splunk Aug 22, 2024

Choose a reason for hiding this comment

awownysz-splunk Aug 22, 2024

Choose a reason for hiding this comment

awownysz-splunk commented Aug 22, 2024

awownysz-splunk commented Aug 22, 2024 • edited Loading

Latest updates

Testing done

awownysz-splunk commented Aug 26, 2024

Latest updates v2

Testing done

Tests on push to develop

Tests on push to release branch:

Validation of existing release version:

mkolasinski-splunk left a comment

Choose a reason for hiding this comment

awownysz-splunk commented Aug 27, 2024

srv-rr-github-token commented Sep 3, 2024

kgwizdz-splunk commented Aug 12, 2024 •

edited

Loading

awownysz-splunk commented Aug 22, 2024 •

edited

Loading

Tests on push to `develop`