henrypham67
commented
1 year ago Proposed solutions
Scenario 1: Check the existence of PR semver on non-master
if PR is 'opened' from a non-master branch then use 'grep' to check whether regex is contained in github.event.pull_request.body or title
Scenario 2: Print semver on a new commit
On all push, extract semver from PR
Check existence of a tag with git describe --tags
Extract semver using grep
if not then print semver with the latest GitHub Actions build version
Scenario 3: Check whether semver is removed from the PR title and description
When PR is edited Get the title and body before and after being edited Check if semver is included in changes
Scenario 4: Create a release branch when a PR with major or minor is merged
Extend from Scenario 7 workflow Create a branch if the PR has a major or minor version
Scenario 5: Prevent a patch PR to master
When a PR is opened to master, get the semver and compare it with the master's semver If only the patch version is changed then exit 1
Scenario 6: Check PR patch version is compatible with the release or not
Extracts the patch version from the pull request's title or body. Parses the release version to get the major and minor version numbers. Compares the major and minor version numbers of the release with the patch version from the pull request to determine if they are compatible.
Scenario 7: Create a tag for release when merging a PR (#scenario7)
Listens for a pull request to be closed and checks if: github.event.pull_request.merged == true.
Extracts the version number from the pull request's title or body.
Creates a git tag for the version number.
Pushes the tag to the repository git tag -a ${{ version }} -m "Release ${{ version }}".
Scenario 8: Create a tag for a pre-release or build when merging a PR to master
Extend Scenario 7 workflow Write job triggered on branch master Extracts the version number and release type from the pull request's title or body. Creates a git tag for the version number with the appropriate release type. Pushes the tag to the repository.
Scenario 9: Check if a beta tag should be promoted to an rc tag or fail if an rc tag already exists
Extend Scenario 7 workflow Add job check +semver:pre && target branch == master && latest tag
Our project does not (yet) have a way to manage Semantic Versioning (semver).
It is time to lay the groundwork for automatic sem versioning.
Please keep in my that the first version in our project is always v0.1.0-alpha+{CI_BUILD_NUM}
UserStory
As a contributor, I want to be able to make sure I always specify the semantic version of my PR changes, so that the CICD system can automatically run tests against past releases, and determine the correct semver of my PR,
and push a new git tag for the semver when my PR is merged to master or a release branch.
Behaviours
Scenario 1: Check the existence of PR semver on non-master
Given a branch that is not master branch, When a PR is created from this branch without any +semver:xxx in its title or description, Then Github Action should fail
Scenario 2: Print semver on a new commit
Given a PR with title or description containing +semver:major or +semver:minor or +semver:patch or +semver:pre or +semver:build, and there is currently NO tag, and the next latest CI build number is 100, When a new commit is pushed, Then Github Action should print the correct version of the PR which means:
Scenario 3: Check whether semver is removed from the PR title and description
Given a PR with title or description containing +semver:major or +semver:minor or +semver:patch or +semver:pre or +semver:build, When the +semver:xxx is removed from both its title and description, Then Github Action should fail.
Scenario 4: Create a release branch when a PR with major or minor is merged
Given a PR with title or description containing +semver:major or +semver:minor, and the
latestversion is v0.1.0-alpha+100" and the next latest CI build number is 123 and NO string "+semver:release" is included/contained in the PR title When the PR is merged to master branch, Then Github Action should tag the master commit with the correct version, and a new branch prefixed with release/v0.1** is created from the merged commit. and a new tag is created with name beingScenario 5: Prevent a patch PR to master
Given a PR with title or description containing +semver:patch, and the PR is targeted to the master branch, When the Github Action runs Then Github Action should fail.
Scenario 6: Check PR patch version is compatible with the release or not
Given a PR with title or description containing +semver:patch, and the PR is targeted to branch release/vX.Y where X and Y are the major and minor version of the semver number respectively, When the Github Action runs Then Github Action should pass.
Scenario 7: Create a tag for release when merging a PR
Given a PR with title or description containing +semver:patch, and the PR is targeted to branch release/vX.Y where X and Y are the major and minor version of the semver number respectively, When the PR is merged Then Github Action should tag the merged commit with the correct version.
Scenario 8: Create a tag for a pre-release or build when merging a PR to master
Given a PR with title or description containing +semver:pre or +semver:build, and the PR is targeted to master branch, When the PR is merged Then Github Action should tag the merged commit with the correct version, and the previous tag of the same precedence should be deleted.
Scenario 9: Check if a beta tag should be promoted to an rc tag or fail if an rc tag already exists
Given a PR with title or description containing +semver:pre, and the PR is targeted to master branch, and the current CI Build Number is 100, and the latest tag is either
and NO string "+semver:release" is included/contained in the PR title When the Github Action runs Then Github Action should