diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 000000000..7e9aab6dc --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,13 @@ +### Description + +(PR description goes here) + +### Checklist + +- [ ] `README.md` has been updated or is not required +- [ ] push trigger tests +- [ ] manual release test +- [ ] automated releaes test +- [ ] pull request trigger tests +- [ ] schedule trigger tests +- [ ] workflow errors/warnings reviewed and addressed diff --git a/.github/workflows/reusable-build-test-release.yml b/.github/workflows/reusable-build-test-release.yml index 5a0f81e44..0c18bfdd0 100644 --- a/.github/workflows/reusable-build-test-release.yml +++ b/.github/workflows/reusable-build-test-release.yml @@ -2333,7 +2333,7 @@ jobs: summary-scripted* pre-publish: - if: ${{ !cancelled() && needs.validate-custom-version.result == 'success' }} + if: ${{ !cancelled() }} # The following line will rename 'pre-publish' to 'pre-publish-not_main_pr' when PR is created towards main branch # It is necessary to avoid confusion caused by githubactions considering pre-publish for both push to develop branch # and pull_request to main branch events. @@ -2377,8 +2377,9 @@ jobs: publish: if: | - (!cancelled() && needs.pre-publish.result == 'success' && github.event_name != 'pull_request' && github.event_name != 'schedule') || + (!cancelled() && needs.pre-publish.result == 'success' && github.event_name == 'push' && github.event.inputs.custom-version == '') || (!cancelled() && needs.pre-publish.result == 'success' && github.event.inputs.custom-version != '' && needs.validate-custom-version.result == 'success') + # First condition for standard release process, second one for manual custom-version release process name: ${{ github.event.inputs.custom-version == '' && 'publish' || 'publish-custom-version' }} needs: diff --git a/README.md b/README.md index 3a801f20c..b7e8bde0e 100644 --- a/README.md +++ b/README.md @@ -17,13 +17,25 @@ Workflow defines jobs which perform security code scanning, execute different ty * If bugfix release is needed: * make a change * test it + * pull-request scenario + * push scenario + * release scenario (test-addonfactory-repository) * create a PR to the `main` branch * get all the approvals from the team * merge it using "squash commit" option * backport the change back to the `develop` branch * new version of the workflow is going to be released (v4.17.0 (before) -> v4.17.1 (after)) and it will automatically applied to all the repositories -# Troubleshooting for different workflow stages in GitHub Actions +# Workflow jobs + +## Inputs +* marker - list of markers used to paralelize modinput tests +* ui_marker - list of markers used to paralelize ui tests +* custom-version - version used for release on manual workflow trigger +* execute-tests-on-push-to-release - enable tests on release branch - default false +* k8s-enfironment - k8s environment for testing +* k8s-manifests-branch - k8s-manifests branch for testing +* scripted-inputs-os-list - list of OSes used for scripted inputs tests ## General troubleshooting diff --git a/runbooks/backporting-changes-to-older-version.md b/runbooks/backporting-changes-to-older-version.md new file mode 100644 index 000000000..4e94084ad --- /dev/null +++ b/runbooks/backporting-changes-to-older-version.md @@ -0,0 +1,52 @@ +# Runbook to backport changes to previous versions of `addonfactory-workflow-addon-release` +`addonfactory-workflow-addon-release` is utilized by all supported TAs. While it is strongly recommended to use the latest minor version of the reusable action, not all TAs consistently follow this guideline. As a result, there are cases when crucial updates introduced in the latest reusable workflow version need to be backported to its older versions that are still in use. + +This runbook shows a real example of backporting changes correlated to `ta-automation-k8s-manifests`. In the example: +- current version of `addonfactory-workflow-addon-release` is `v4.17.0` +- there was a bug in `ta-automation-k8s-manifests` affecting all TAs + - there is a need to make a fix and release `v4.17.1` containing fixed `ta-automation-k8s-manifests` version ([PR](https://github.com/splunk/addonfactory-workflow-addon-release/pull/329)) + - there is need to backport it to `v4.16` (the old version which is still in use by some TAs) + - the latest patch release of `v4.16` is `v4.16.14` +### Steps +- make release `v4.17.1` with necessary changes +- fetch all existing tags from `addonfactory-workflow-addon-release`: + ``` + git checkout main + git pull + git fetch --tags + ``` +- checkout to the latest tag of the minor release you want to backport the changes to + ``` + git checkout v4.16.14 + ``` +- create a new branch based on the tag you are currently checked out to + ``` + git checkout -b fix/bump-k8s-manifest-version + ``` +- changes made in `ta-automation-k8s-manifests` were correlated with changes in `addonfactory-workflow-addon-release`, so there is a need to backport **only necessary** changes to `v4.16`. There are two ways to do that: by cherrypicking specific commits (and resolving the conflicts if they exist) or by commiting necessary changes manually. + - for example make necessary changes and commit them: + ``` + git add .github/workflows/reusable-build-test-release.yml + git commit -m "fix: bump k8s-manifest version" + ``` +- push newly created branch to the remote repository + - ```git push -u origin fix/bump-k8s-manifest-version``` +- in GitHub UI: + - navigate to releases + - draft a new release + - `Choose a tag`: type the tag that will be created, i.e. `v4.16.15` + - `Target` - newly created branch `fix/bump-k8s-manifest-version` + - click on `Generate release notes` + - `Title of release` should be `v4.16.15 backport` + - write description of the changes + - uncheck `Set as the latest release` box + - click `Publish release` + - check if the release is available, and it points at the proper version - https://github.com/splunk/addonfactory-workflow-addon-release/tags tag `v4.16` should point to the same commit as tag `v4.16.15` + tags + Backporting changes will cause that the tag `v4` will point at the same commit as `v4.16`. To make it proper one has to either re-trigger the workflow which produced the latest tag (`v4.17.1`) or resolve that manually: + ``` + git fetch --tags -f + git tag -f v4 v4.17.1 + git push -f --tags + ``` +- run the workflow for some TA using v4.16 to verify if the pipeline works as expected. \ No newline at end of file diff --git a/runbooks/images/backporting/compare-tags.png b/runbooks/images/backporting/compare-tags.png new file mode 100644 index 000000000..df128fddd Binary files /dev/null and b/runbooks/images/backporting/compare-tags.png differ