stop removing tags from your repo

[brjsp]

Hello. I maintain the electron package in openSUSE.

Yesterday you have added a v29.3.2 tag to the repository. It was live long enough for me to download the tarball and start preparing the release.

It is impossible now to verify which commit the source code corresponds to, because you have deleted the tag. I managed to catch this before publishing the new version but you are wasting time of me, the openSUSE release team, and possibly my counterparts in other distros. I'm going to tag them just to alert them to this bad practice of yours: @alerque @selfisekai @tagattie

[brjsp]

The tagged commit seems to be 19f0abd

[alerque]

Yes, very much the same complaint here. I am the packager for all the official Arch Linux packages. The practice of re-tagging on this repo has cost me quite a bit of time in the past and is a regular source of frustration. I've complained about it in the past too, but it keeps happening.

It would be much appreciated if a different workflow could be setup. If a release goes wrong and you want to get some extra commit it, just tag a new minor version. Or figure out a way to run your release checks privately without pushing the tag to the public repo until you know it is good to go.

@brjsp You can usually identify what commit a tarball is from (assuming it is a git archive generated one) with zcat package.tar.gz | git get-tar-commit-id.

[selfisekai]

alpine linux package maintainer here, i think i haven't noticed it myself before on this repo, actually. though i think i'm also the only one here only tracking one branch at a time

[MarshallOfSound]

Hey folks, appreciate there is a disconnect here. Unfortunately changing how we do tags / releases is not a thing that would be easy to do, even if we wanted to do it.

For clarity, if at any point the release process fails in an unrecoverable way we initiate a "clean up" that removes all our temporary artifacts and deletes the tag completely. This, along with the rest of our release process, is fully automated.

If you're looking for a clear indication of "when an electron release is actually released" you can operate off of either:

• npm version tags (once it's live on npm, it's actually live)
• github releases (not tags), the tag is made quite early during the release process, an associated release is only published as the final step
• Operate off of our canonical Source Of Truth for electron releases. https://releases.electronjs.org (or the JSON feed https://releases.electronjs.org/releases.json). Things only show up in that feed when they've been published.

I managed to catch this before publishing the new version but you are wasting time of me, the openSUSE release team, and possibly my counterparts in other distros

Just want to note here, this isn't a thing we actively support / know y'all are doing. So to be fair, it's not like we're doing it deliberately

[alerque]

Thanks for the response. Just a couple points:

1. I did switch from starting test releases when a tag landed to not launching anything until it lands as an announcement on releases.elctronjs.org. That is not as infallible as you suggest though, twice now releases have been posted there only to later disappear with no explanation.
2. The GH Releases system has some glitches too, it is not uncommon for a release to get missed entirely there, and other times they get labeled as pre-releases and the label never removed even long after the release is posted on the website and even the next release lands.
3. Deleting half-baked artifacts is one thing, but yanking the tag with no visible explanation and eventually re-posting the same number is definitely an anti-pattern.

[MarshallOfSound]

That is not as infallible as you suggest though, twice now releases have been posted there only to later disappear with no explanation.

I'd be interested in version numbers for these cases, we keep detailed release logs and it shouldn't be possible for a release to show up on releases.electronjs.org and then later be removed 🤔 I can chase down why that is occurring.

other times they get labeled as pre-releases

Not sure what this is referring to specifically, but we label and leave all "alpha" and "beta" releases as pre-release. There shouldn't be any stable x.y.z versions tagged as "pre-release" on github.

Deleting half-baked artifacts is one thing, but yanking the tag with no visible explanation and eventually re-posting the same number is definitely an anti-pattern.

I don't necessarily disagree, just noting how things currently work and that changing them is unlikely to be a thing. What we can do is make sure there is something that y'all can use as a source of truth, I believe it is releases.electronjs.org but if that is exhibiting similar conditions then that might be something we have to look into as noted above.

[brjsp]

@brjsp You can usually identify what commit a tarball is from (assuming it is a git archive generated one) with zcat package.tar.gz | git get-tar-commit-id.

@alerque We don't do “use git archive and add a separate tarball with vendored stuff” for Electron. It's impractical as the bulk of the code is patched Chromium, and the “main” repo lives in an electron/ subdirectory. We just download everything using gclient and remove the irrelevant libraries and binary blobs afterwards (since we would have to do that anyway) — the git metadata do not survive that process.

See the script we're using.

[alerque]

29.1.1 is one tag that hit the releases website and then later wasn't there for an extended time. I had a bit of an exchange with a RISC-V packager for an Arch Linux port about it and tried to defend it being there when he couldn't find it, and then eventually force refreshed my browser on the announcement page and got a 404. The tag had lived on Git for at least a couple days, then was gone for about a week at least (Mar 1st–6th) before coming back with lots of new content. At the time that happened I remembered it having happened before but I do not have a record of what tag it was.

Is there a public build log somewhere that we could check to see if a release was pulled and see what commit SHA was originally tagged? That would be quite useful for us distro packagers to review.

[alerque]

@brjsp Understood, and yes that would loose the meta data (c.f. my request for a log of yanked tags and their commit hashes), and yes I understand why you've taken that route to handling the sources. We did something similar for a long time, and now take a bit different tactic: We scripted something up that iterates through the sources manifest for a given release and finds all the pinned commits for vendered sources, then regenerates this list of sources that we can checkout using a sources cache that is available across builds and even Electron versions to save bandwidth and local storage while still tracking hashes for all our input sources.

[brjsp]

regenerates this list of sources that we can checkout using a sources cache that is available across builds

@alerque Looking at that list, this is something we (openSUSE) very much do not want to do. Half of these libraries are unused in fact (grep our script for keeplibs) and our policy requires us to actually keep a copy of the source, not just provide hashes.

(Also, our diff view on OBS seems not to like multiple versioned tarballs).

[alerque]

Understood, I wasn't suggesting you copy the approach. There are definitely pros and cons to each possible way, and we've tried quite a few for this project. This is the best suited to our build tooling so far. And no Arch does not keep archived copies of source inputs like OpenSUSE, Debian, and a few others do. We do have hashes not jsut for the sources but for every file in the sources too, and this is useful for comparing with the sources being used in other distros. See e.g. electron30 on whatsrc.org.

Thanks for the pointer on your keeplibs list. I might review that as a way to trim our source setup.

[brjsp]

alpine linux package maintainer here, i think i haven't noticed it myself before on this repo, actually. though i think i'm also the only one here only tracking one branch at a time

@selfisekai At openSUSE we also track only one branch (we neither have resources for maintaining multiple versions nor has such a need come up yet). Though i rather tend to follow https://3rdpartysource.microsoft.com/ for the question of “what is the latest stable version” rather than github, since VSCode (the most complicated app we ship) likes to break in unexpected ways (I recall 15 and 23 being problematic in that — both are Electron branches that bumped the Node major)