Feat - Automated Releases #1007
Open
Conversation
This file contains hidden or 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
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.
hi
With SVT-AV1 3.0.4 that improved arm64 encoding performance (NEON), I wanted to test out av1an over ab-av1 to benchmark the differences.
Although I could simply build av1an from master for my own use, seeing that the last av1an release was in late 2024, I wanted to see if I could automate parts of the av1an release process to make it easier for av1an to push new versions out.
I've put together a initial workflow that can be triggered manually with a new version string, it then takes care of updating the version numbers in Cargo.toml files for av1an and av1an-core and would make sure the main workspace definition is consistent. it'd then commit these changes, creates a tag, and pushes both.
I've also updated the existing tests.yml workflow so that it automatically runs on these new tags.
for now, I've kept this workflow lean, full validation still happens in tests.yml, which kicks off after the tag is pushed, though this could be changed.
Are maintainers here open this pull to automate versioning and tagging? If I'm given the go-ahead, I'd extend beyond this to also automatically generate changelogs and create GitHub Releases for the new tag with changelogs... before I build further, I need to know if this is a welcomed change
(I'll drop the first two commits)