New tag == new release ?

[iskunk]

Currently, on this repo's front page, under "Releases" it says "7 tags." This implies that each tag equates to a release.

Using the "Watch" widget, I've subscribed to notifications for this repo, specifically via "Custom -> [x] Releases." I want to get an e-mail each time a new tarball comes out, which equals a new tag, which should equal a new release. But that does not appear to be happening, or at least it didn't for 133.0.6847.2.

I think an explicit step may be needed (beyond just pushing a tag) to cut a new release. Here is a workflow that does exactly that: https://github.com/ungoogled-software/ungoogled-chromium/blob/master/.github/workflows/release-on-tag.yml

(The GitHub Action used there is unmaintained, however. The alternative would be to use gh release create.)

I'd suggest doing releases only for new stable versions, as I think the interest in packaging beta or dev releases would be much more limited. (It does appear that GitHub releases have a "prerelease" flag, but I'm not sure what aspects of the resulting behavior are different.)

[Kangie]

This looks like it would trivially do the job, but we'd have to trigger on all tags.

https://github.com/comnoco/create-release-action

We could prefix the channel to the tags, maybe, but I'm not sure I like that. Maybe we can adapt it to trigger within the tag workflow, like the various IRC channel notifs?

https://github.com/chromium-linux-tarballs/chromium-tarballs/blob/fa02f8cd771dcaaad9b4dc6f06ed4ab4041e779a/.github/workflows/cron.yml#L60-L68

Something like

      - name: Create Release
        id: create_release
        if: steps.tag_versions.outputs.stable != ''
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ steps.tag_versions.outputs.stable_tag }} # We will need to export the tag but that's fine
          release_name: Release ${{ steps.tag_versions.outputs.stable }}
          body: |
          New ${{ steps.tag_versions.outputs.stable }}
          draft: false
          prerelease: false 

We could repeat that for dev/beta as prerelease tags.

[iskunk]

Hmm... one concern I have is the timing. The workflow does the tag, and then does the IRC (and prospectively release) things... but the actual tarball generation starts with the tag. So it can get to the IRC/release part before the tarball is generated and available.

I think consumers of this tarball are going to want to use the release notification to kick off their own CI, so it would be good for the tarball to be done and ready at that point (so they don't have to implement a delay or polling loop).

I'm not sure how to structure it to get that behavior, however... the cron workflow could explicitly call the tarballs workflow, but that would likely result in two runs. And tarballs should legitimately start on a tag op, since you'd want it to run if you push a tag manually (right?). Thoughts?

[Kangie]

There are IRC notifications tied to the CI completing successfully; let's just use that to trigger the release instead?

We already have the tag from the repo at that point in the workflow, which makes it even easier, and we can look up the release quickly to get the string (when it was released upstream, channel, etc) using existing tooling, and just filter off that containing stable

[iskunk]

It seems like the IRC notifications go out right after the tag(s) are pushed, so the tarball build(s) should be just starting at that point, aren't they? What we would need is something that causes the IRC/release bits to wait until the tarball process(es) are complete.

I noticed this bit in the workflow. If you use the regular github.token, can you push a tag, without it starting the tarballs.yml workflow? Because that could be a solution---we then just invoke tarballs.yml explicitly, and wait until it completes. (We also get the benefit that the notifications don't go out if the tarball generation fails.)

---

On a semi-related note: I was looking at get_chromium_versions.py, and thought to myself, "I bet I could do all that with a bit of jq." Please have a look at this.

The main thing I didn't like about the Python script was how its normal usage makes multiple API requests, when really, you can get everything you need from a single request. That's what I did here, with the added benefit that the few lines of jq-script make the Python unnecessary. Let me know what you think---I can make this a PR if it looks promising.

[Kangie]

It seems like the IRC notifications go out right after the tag(s) are pushed, so the tarball build(s) should be just starting at that point, aren't they? What we would need is something that causes the IRC/release bits to wait until the tarball process(es) are complete.

I'm talking more about this in terms of where we would want to run a release action, I should have picked the better example upfront:

https://github.com/chromium-linux-tarballs/chromium-tarballs/blob/fa02f8cd771dcaaad9b4dc6f06ed4ab4041e779a/.github/workflows/tarballs.yml#L99-L107

I noticed this bit in the workflow. If you use the regular github.token, can you push a tag, without it starting the tarballs.yml workflow? Because that could be a solution---we then just invoke tarballs.yml explicitly, and wait until it completes. (We also get the benefit that the notifications don't go out if the tarball generation fails.)

I like the current workflow where a new tag triggers a run, and I'll get the failure notif in #gentoo-chromium if it fails.

I could be convinced now that we have a mechanism that can run this all on one runner; a lot of this split (aside from keeping the cron portion light) was to ensure that we were only using CI minutes / self-hosted runners for the steps that require it - that's no longer an issue.

On a semi-related note: I was looking at get_chromium_versions.py, and thought to myself, "I bet I could do all that with a bit of jq." Please have a look at this.

I spent all weekend parsing cargo metadata with jq. It's pretty flexible!

The main thing I didn't like about the Python script was how its normal usage makes multiple API requests, when really, you can get everything you need from a single request. That's what I did here, with the added benefit that the few lines of jq-script make the Python unnecessary. Let me know what you think---I can make this a PR if it looks promising.

It came initially from some of the automated Google Chrome package updates tooling that I inherited; I just needed a quick PoC to get this working. I'm not super attached to the implementation; if we can do it with jq that's fine too.

[iskunk]

I'm talking more about this in terms of where we would want to run a release action, I should have picked the better example upfront:

Ohh, I see what you mean... that there are IRC notifications for both new upstream releases, and new tarballs, and you're talking about putting the release bit with the latter.

Yes, I think that sounds good, though I'd ask if the IRC/release bits should happen in a manual (workflow_dispatch) invocation. Maybe add a checkbox (boolean input defaulting to true) for those? Perhaps include the upload in that, too?

I like the current workflow where a new tag triggers a run, and I'll get the failure notif in #gentoo-chromium if it fails.

I could be convinced now that we have a mechanism that can run this all on one runner; a lot of this split (aside from keeping the cron portion light) was to ensure that we were only using CI minutes / self-hosted runners for the steps that require it - that's no longer an issue.

I don't see a problem with the split between the two workflows... it makes natural sense to be able to run the tarballs workflow independently of any upstream version checking, like if you wanted to generate an older tarball.

It came initially from some of the automated Google Chrome package updates tooling that I inherited; I just needed a quick PoC to get this working. I'm not super attached to the implementation; if we can do it with jq that's fine too.

All right, will get that PR out!

[Kangie]

Yes, I think that sounds good, though I'd ask if the IRC/release bits should happen in a manual (workflow_dispatch) invocation. Maybe add a checkbox (boolean input defaulting to true) for those? Perhaps include the upload in that, too?

I don't mind the spam in IRC if we are generating manual tarballs and I guess I'd rather know if something has gone wrong and we're generating tons of tarballs before I decide to check my mail in 3 days!

[iskunk]

I don't mind the spam in IRC if we are generating manual tarballs and I guess I'd rather know if something has gone wrong and we're generating tons of tarballs before I decide to check my mail in 3 days!

The thought is that if you're invoking the workflow manually (via the Web UI), you already have feedback via the UI and thus other forms of notification are redundant. But if the IRC messages are not a bother in that case, then it's no big deal. I see that you're doing the release part only in the stable+tag case, which is as conservative as we could want.