Introduces versioning for prereleases - these are tagged as major.minor.patch-prelease.<version>. Every merged PR will have be tagged! This has been tested on a fork and does not clash with release-drafter. For example, a release from 1.0.8-prerelease.0 will still be bumped to 1.0.8 via release-drafter.
This workflow also introduces using a manual actions trigger to deploy a release rather than going to the drafted change log. I've tried to add a safety mechanism by requiring some user input before it can be triggered. Hopefully this will avoid some accidental releases (but of course this is not completely fool proof). It has the same level of security required as someone going into the draft and manually triggering a release that way.
Some additional comments for future actions implementations:
If any bash scripting is used, variables have to be passed to the Github env context to use the values, otherwise the command is passed rather than the value.
Types of changes
What types of changes does your code introduce? Put an x in the boxes that apply
[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionalitiy)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Other (if none of the other choices apply)
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you are unsure about any of the choices, don't hesitate to ask!
[x] Changes have been tested to ensure that fix is effective or that a feature works.
[ ] Changes pass the unit tests
[x] Code has been run through black with the -l 79 flag.
[ ] I have included necessary documentation or comments (as necessary)
[ ] Any dependent changes have been merged and published
Notes
All PRs will undergo the unit testing before being reviewed. You may be requested to explain or make additional changes before the PR is accepted.
Proposed changes
Introduces versioning for prereleases - these are tagged as
major.minor.patch-prelease.<version>. Every merged PR will have be tagged! This has been tested on a fork and does not clash withrelease-drafter. For example, a release from1.0.8-prerelease.0will still be bumped to1.0.8viarelease-drafter.This workflow also introduces using a manual actions trigger to deploy a release rather than going to the drafted change log. I've tried to add a safety mechanism by requiring some user input before it can be triggered. Hopefully this will avoid some accidental releases (but of course this is not completely fool proof). It has the same level of security required as someone going into the draft and manually triggering a release that way.
Some additional comments for future actions implementations:
Types of changes
What types of changes does your code introduce? Put an
xin the boxes that applyChecklist
Put an
xin the boxes that apply. You can also fill these out after creating the PR. If you are unsure about any of the choices, don't hesitate to ask!blackwith the-l 79flag.Notes
All PRs will undergo the unit testing before being reviewed. You may be requested to explain or make additional changes before the PR is accepted.
_PR template was adopted from appium_