Add a GitHub workflow to prepare a release pull request #6972
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
CC @azhavoro |
Codecov Report
@@ Coverage Diff @@
## develop #6972 +/- ##
========================================
Coverage 82.58% 82.58%
========================================
Files 360 360
Lines 38914 38924 +10
Branches 3570 3570
========================================
+ Hits 32137 32146 +9
- Misses 6777 6778 +1
|
|
I also see that it would be nice to have some validation on the version number that prevents increasing one of X, Y or Z on more than 1. Or was it already implemented and I missed it? |
IMO, this isn't needed. There's no requirement that versions have to be sequential, and we might end up wanting to skip a version for whatever reason. Although now that you mention it, maybe I should at least add a check that the release does not already exist... |
SpecLad
force-pushed
the
release-pr-workflow
branch
2 times, most recently
from
41b59bd
to
50a5949
Compare
This automates the first half of the current release process. The second half will be implemented by another workflow. The reason why it can't all be done in a single workflow is that it's useful to let developers inspect what'll go into the release before actually publishing it, and to apply any last-minute fixes, if necessary. It also allows CI to complete for the release PR. To support the new workflow, add a `--set` option to `update_version.py` that sets the version to a custom value.
SpecLad
force-pushed
the
release-pr-workflow
branch
from
50a5949
to
046aa62
Compare
sizov-kirill
approved these changes
Oct 11, 2023
mikhail-treskin
pushed a commit
to retailnext/cvat
that referenced
this pull request
Oct 25, 2023
This automates the first half of the current release process. The second half will be implemented by another workflow. The reason why it can't all be done in a single workflow is that it's useful to let developers inspect what'll go into the release before actually publishing it, and to apply any last-minute fixes, if necessary. It also allows CI to complete for the release PR. To support the new workflow, add a `--set` option to `update_version.py` that sets the version to a custom value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and context
This automates the first half of the current release process. The second half will be implemented by another workflow.
The reason why it can't all be done in a single workflow is that it's useful to let developers inspect what'll go into the release before actually publishing it, and to apply any last-minute fixes, if necessary. It also allows CI to complete for the release PR.
To support the new workflow, add a
--setoption toupdate_version.pythat sets the version to a custom value.How has this been tested?
Manual testing on my fork of CVAT. See a test run here: https://github.com/SpecLad/cvat/actions/runs/6459901481.
Checklist
developbranch[ ] I have created a changelog fragment[ ] I have updated the documentation accordingly[ ] I have added tests to cover my changes[ ] I have linked related issues (see GitHub docs)[ ] I have increased versions of npm packages if it is necessary(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)
License
Feel free to contact the maintainers if that's a concern.