"tagging" a snap revision?

For finding bugs we play long-running (e.g. 2months) freeorion games with fixed game revisions, and I provide a snap build to players who are not able to build themselves.

Currently I re-release a specific snap revision to a branch channel e.g. latest/beta/slow-game-022 . I was off for ~three weeks so the branch channel timed out and the freeorion clients reverted to the beta channel.

Also it is not possible to look at old games e.g. latest/beta/slow-game-020 because the branch channel is not available in the store anymore.

So I was wandering if there is an equivalent to a git tag / or a way for the players to install a specific revision (e.g. freeorion revision 323).

Very rarely we find bugs which are so game-breaking that we have to rebuild/change the revision while playing on. But those are rare, so manually refreshing to a different tag/revision is acceptable. So in git terms, the changes are rather tag-like than branch-like.

Is there a better way to handle this? A way to manually install a certain revision?

Would be requesting a separate track per slow game adequate?

I won’t common on the track aspect because there’s a review system in place for that and I’m not a reviewer; but regarding keeping things as branches; it’s possible to override a specific revision on a branch so that it doesn’t expire at all (or at least for a few decades).

It’s something you’d need to apply for each time, and since it’s per revision, if you push a new revision to the same branch you’d need to ask again. But it might be slightly more preferable than tracks because tracks appear quite publically in the API and will be offered to all players; they’re also effectively impossible to remove, because if a track were to stop existing, there wouldn’t be any fallback; their installation would just be effectively orphaned and stop updating ever (unless they manually intervened).

So maybe it’d make more sense to ask for a branch to be over-ridden to last for say, a year, than it would be for a track to be created publically, permamently.

I don’t have the ability to re-assign your thread but I’d suggest you’d put it in “Store” instead, if not “store-requests” if you want to formalise a request; “Snapcraft” is for the build tool and our store expert Daniel might not see it otherwise!

thank you James-Carroll for the fast answer. I am not sure I understood the “override a specific revision on a branch so that it doesn’t expire at all”, is that some something I can do with the snapcraft tool or do I have to request that in store-requests? I think pinning the revision of a branch for a year would work well.

thank you for the suggestion, moved the question to “store-requests”, hope Daniel sees it

@roadmr I think you are the store expert Daniel that James-Carroll mentioned - could you have a short look?

for reference, i think we had about 23 of those specific branches/tagged revisions in the last two (or three?) years.

I guess to make it more tangible, I should start by requesting to override the revision for snap “freeorion” for channel “latest/beta/slow-game-022” to revision “323” for forever

Hi,

Branches are meant to be temporary - and as I understand it, these branches only need to live for a few months.

We prefer to limit the instances in which we tweak branch lifetimes because it’s pretty manual and cumbersome, but perhaps I can offer an alternative that on the other hand you can fully control.

If you are able to set up a periodic process somewhere, you can simply “rerelease” the same revision to the branch, this will “reset” the counter and make the branch available for another 30 days. So if you run this every 29 days you should be good to go:

snap release freeorion --channel latest/beta/slow-game-022 323

Let me know if that covers your needs.

  • Daniel
1 Like

i dont have a reliable place currently to set that up - also i am not sure about login implications (e.g. when does the snapcraft access token time out). so i have a bit of an stomach ache with this solution.

On the other hand if it breaks it probably does not do much damage (if the players figure out the version did change and stop playing). We would fix the problem manually and restart the process to rerelease.

If there is no better tooling, I guess it is good enough to try and see how long it takes to break and see if that is acceptable or not.