Did some testing this morning to try to get the release version update working. Decided to simplify the workflows a little now that we have 2 apps (test and prod).
CI workflow will now only update the changelog upon deployment afids-validator-test. Deployment to test will cause an update to the version in setup.py to be updated as necessary. This means that the master branch will always have the newest tag and may not match the version deployed to the production afids-validator.
Release workflow uses github.ref to grab the latest release tag, and pushes the released version to production afids-validator.
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)
[ ] 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!
[ ] Changes have been tested to ensure that fix is effective or that a feature works.
[ ] Changes pass the unit tests
[ ] 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
Did some testing this morning to try to get the release version update working. Decided to simplify the workflows a little now that we have 2 apps (test and prod).
CI workflow will now only update the changelog upon deployment
afids-validator-test. Deployment to test will cause an update to the version insetup.pyto be updated as necessary. This means that themasterbranch will always have the newest tag and may not match the version deployed to the productionafids-validator.Release workflow uses
github.refto grab the latest release tag, and pushes the released version to productionafids-validator.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_