Closed jnsgruk closed 11 months ago
A note that one thing we could consider is including the version of the upstream project in the tag, e.g. for Signal we could have something like 6.42.0/rev576/amd64
- happy to iterate on the format.
+1 for adding the snap version to the tag, this will make it more clear, imo. I'll take a better look at this PR later.
@merlijn-sebrechts version added to tag name in 78edeec
(#23)
Hey :wave:
So as discussed in our catch-up meet, here is a first draft of how we might want to create tags automatically in repositories based on the revisions that were released to the store. The aim here is to make debugging issues a little easier, as when an issue is reported on a snap with a given revision, you can just checkout the tag and build/install/troubleshoot.
It's a little complicated with multiple architectures. The design I've chosen is to create one tag per revision, and name with the arch just to make searching/bisecting easier. The tag names will be
rev<num>/<arch>
.You can see an example run here and the resulting tags here.
I should note that this is actually a breaking change because all repos that use these workflows will need to add a new input to the release workflow. I think if we merge this, we should tag the repo at
v1
, and work on using the actions with a versioned reference like@v1
rather than@main
.If this does merge, I'll do some follow-up PRs to address the incompatibilities on the other repos.