build: Support building new revisions for tags #89
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
A new action has been created in build_revision.yaml with a workflow dispatch that takes two optional input parameters, tag and revision. If provided, the release with the tag will be adjusted with new builds versionened with the revision. Otherwise the latest tag is determined, its release information fetched and the current package revision determined from that, then incremented by one to act as the new revision. The goal of this action is to be able to do additional builds of the *same* code version, against a newer dependency versions (e.g. on a libcamera0 update).
|
Just a ping to make sure this doesn't get overlooked :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
A new action has been created in build_revision.yaml with a workflow dispatch that takes two optional input parameters, tag and revision.
If provided, the release with the tag will be adjusted with new builds versionened with the revision.
Otherwise the latest tag is determined, its release information fetched and the current package revision determined from that, then incremented by one to act as the new revision.
The goal of this action is to be able to do additional builds of the same code version, against a newer dependency versions (e.g. on a libcamera0 update). I have a workflow that implements this functionality as well and have that already running on OctoPrint's fork of this repo. It detects changed libcamera0 versions (scheduled check every our at the 42 minute mark) and triggers a revision build against the latest tag in such a case. Once this PR is merged I can provided that as well.
This should mean way less of an operational overhead to react to libcamera0 changes in the future, with fully automated PR generation against apt.octoprint.org as well (by an action that's already in place and operational there), and further possibilities like that for other projects. With a libcamera0 version pin being necessary the way it is, this is needed to keep maintenance on all sides feasible.