This PR adds in automatic version management using release-drafter, where release notes are automatically drafted / updated from PR titles (so please make sure these are meaningful moving forward) and performs version bumping as necessary. This largely follows semantic versioning, but is based off of the labels assigned to a PR. As such, the labels are also important:
skip_changelog - will ignore the PR in the drafted release notes
breaking - will trigger a major release bump
enhancement will trigger a minor release bump
bug, maintenance, and dependency will trigger patch bumps
If none of these are specified, it will default to a patch bump.
~Will note that this currently has no way of updating any files within the repository and am looking into a way of possibly grabbing the version from the latest published release and updating a package.json file or such.~
As of 34452ab, a version has been added to setup.py and has been tested to work on a forked branch. This version only gets bumped if a deployment to heroku happens (similar to publishing the release notes). It uses gha-find-replace to find the version in setup.py via regex, and replaces it using the tag from release-drafter. This is all done local to the action, so the github-actions bot credentials are used to commit the changes as part of the workflow and pushes it back the master branch.
Note: This is currently failing the github actions, but taking a look at it, it seems like this error is happening because there is no corresponding YAML file in the default branch
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)
[ ] 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.
[x] Changes pass the unit tests
[x] Code has been run through black with the -l 79 flag.
[x] 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
This PR adds in automatic version management using
release-drafter, where release notes are automatically drafted / updated from PR titles (so please make sure these are meaningful moving forward) and performs version bumping as necessary. This largely follows semantic versioning, but is based off of the labels assigned to a PR. As such, the labels are also important:skip_changelog- will ignore the PR in the drafted release notesbreaking- will trigger a major release bumpenhancementwill trigger a minor release bumpbug,maintenance, anddependencywill trigger patch bumpsIf none of these are specified, it will default to a patch bump.
~Will note that this currently has no way of updating any files within the repository and am looking into a way of possibly grabbing the version from the latest published release and updating a
package.jsonfile or such.~ As of 34452ab, a version has been added tosetup.pyand has been tested to work on a forked branch. This version only gets bumped if a deployment to heroku happens (similar to publishing the release notes). It usesgha-find-replaceto find the version insetup.pyvia regex, and replaces it using the tag fromrelease-drafter. This is all done local to the action, so the github-actions bot credentials are used to commit the changes as part of the workflow and pushes it back themasterbranch.Note: This is currently failing the github actions, but taking a look at it, it seems like this error is happening because there is no corresponding
YAMLfile in the default branchTypes 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_