Hi there.
I have created a set of branches for Subiquity of latest/stable/ubuntu-18.04.x. I would like them, seven in total, to have their expiration disabled.
The oldest of them is currently set to expire in 25 days.
Thanks.
-Dan
@roadmr would you be able to help with this request?
Sure thing, I’ll poke you once it’s done. (By my count we still have at least 10 days but it won’t take that long :))
@roadmr - thanks for taking a look. I think maybe you were starting to ask me something, is there more info needed?
Sorry I took so long to do this. I’ve updated all the expirations for those branches to a date far into the future (and I mean far - we won’t be around to see them expire).
Do note that if you release any new revisions to these branches, the expiration date will re-reset to then+30 days.
@roadmr - would you take a look again? At the time the expiration date didn’t change, and I’ve worked around it since then by just re-promoting old snaps.
Hi,
the records I overrode back in May are still there, with an expiration date of 2999-01-31 15:00:00. They were superseded on May 23rd; superseded means that something else was released with that branch, and that obsoletes the entries with the tweaked expiration date.
I can re-jiggle the expiration date for what’s currently published in those branches, just want to clarify how this works. Branches sound like “containers of releases” but they’re really not - they are more of a “tag” for a release, and it’s on that “tag” that we set the expiration date. Further, when you do a new release, it doesn’t update the branch (tag), but creates a new one superseding the previous one. So if you release, even the same revision, with a branch, it will “reset” the expiration times we had configured on the previous release entry.
So per the above, one might think that once I change the expiration time on a branch, any release to that branch will keep the long expiration time (container branch), but in reality, a re-release resets the expiration time (newly-created tag).
Just keep the above in mind: long-lived branches are meant to be exactly that - long-lived, with the same release, and you should not release anything else to them if you want to keep the long expiration.
Let me know of the branches you need us to fix and I’ll gladly update the expiration dates again.
Thank you for taking a look so quickly. After the override in May, I checked the Web UI and it looked similar to this:
So I did do supersedes later, since it appeared that I had to. Is this just a display problem and it would have been fine if I had ignored that countdown of days?
ugh - it might have been a display issue. I’d actually be interested in debugging this - if you are OK with me updating the expiration dates, I can do so, and I’ll ask you to then check the countdown makes sense. Note that the expiration date I’m using is over 35000 days away so I hope that display is “humanized” somehow (even so, 977 years is going to look super funny). If it still displays something like 18 days we can check with the web team to figure out how they calculate branch expiration dates.
Let’s do it. This scenario sounds likely to me.
hi @dbungert I have updated branch expirations to far into the future, for 35 total releases (that’s 7 branches x 5 architectures) for the subiquity snap.
Please check on your side the expiration dates look far in the future; if they look even remotely close to expiring this century do let me know.
Something is still off, unfortunately. In the Web UI:
And as reported by snapcraft status subiquity - here is an example, all 35 cases have an equivalent result.
Track Arch Channel Version Revision Expires at
stable/ubuntu-18.04 22.02.2 3119 2022-11-04T15:48:55Z
Thanks for the detailed info! Let me check how snapcraft gets this information.
OK, the expiration date for branches is kept in two places, only the one I had modified earlier is actually used to calculate expiration and close expired branches, so it would have worked fine 
- but in order to avoid confusion, I changed it in the other place as well, which is only used for display by charmcraft and the web UI. Things should work as expected now.
Nice, the situation is much better @roadmr.
The Web UI probably needs a fix, as it reports that the expiration in now 15 days, but snapcraft status subiquity reports an expiration 200 years out.
Thank you!
Unfortunately, they aged out. The previous web UI date appears to have been the real one. I have reopened the channels again.
OK, sounds like extended branch lifetime is just broken. We’ll look into it. Sorry for the trouble.
https://bugs.launchpad.net/snapstore-server/+bug/1995480 might be related.
Hi,
Expiration date is now pushed very very far away.
Let us know if you find any issues.
Cheers,