ci: Revamp release workflow by Venefilyn · Pull Request #22630 · cockpit-project/cockpit

Venefilyn · 2025-11-27T23:16:12Z

This revamps the release workflow to be manually triggered if something goes bad without having to create a new release

Coincidentally, this made it possible to experiment with the flathub PR creation which now works as it should. I've created a secret env within cockpit-project/cockpit already so the workflow should function when merged.
https://github.com/Venefilyn/cockpit/actions/runs/19749612709/job/56590267873

Successful run here with some things were commented out to prevent accidental pushes to cockpit-project, hence failing node-cache
https://github.com/Venefilyn/cockpit/actions/runs/20852299144

And for working flathub workflow you can see that here
https://github.com/Venefilyn/cockpit/actions/runs/19747486121/job/56584524019

Dependencies:

PR doc: Prebundle docs on RHEL & CentOS #22693
Adjust guide workflow to tarballs containing built guide (preferably in separate PR)
Rebase this

jelly

I'm not a fan of splitting this up, our current workflow has dependencies so everything is easily observable from our view.

The current workflow is fully re-runnable, we can delete the release and re-run the workflow successfully.

Venefilyn · 2025-12-16T12:43:58Z

I'm not a fan of splitting this up, our current workflow has dependencies so everything is easily observable from our view.

The current workflow is fully re-runnable, we can delete the release and re-run the workflow successfully.

But how do we run these workflows on existing releases or without it being related to a release at all? This split-up makes it so we can trigger each job by itself without having a release or mess about by deleting releases etc.

It is the reason why I was able to test the flathub release workflow for us so easily after this split. We still get the same structure for the release workflow and is the one we care about most of the time and we can trigger just this one and it should work exactly the same as the current workflow:

martinpitt

Thanks! I am okay with splitting out the guide and flathub workflows, that's actually nice to be able to fix them more easily.

.github/workflows/node-cache.yml

martinpitt · 2026-01-08T09:02:43Z

.github/workflows/release-flathub.yml

+  flathub:
+    environment: flathub
+    env:
+      COCKPITUOUS_TOKEN: ${{ secrets.COCKPITUOUS_TOKEN }}


This doesn't currently exist in bots.git or cockpituous.git, so that would have to be set up first. Someone apparently added COCKPITUOUS_TOKEN to the "flathub" env manually, but this really needs to live in CI. Do you know what's the origin of that token? (It's painful to log in as cockpituous, I didn't do that now)

We used this token before when creating a branch in our flathub fork, but that's as much as I know of its usage

.github/workflows/release-flathub.yml

martinpitt · 2026-01-08T09:08:57Z

.github/workflows/release-flathub.yml

@@ -0,0 +1,118 @@
+name: Release on flathub


I can be talked into accepting this for flathub. I'm admittedly nervous about it, as it loses the tight coupling of "single source of truth" of the computed checksum. But if someone can manipulate our tarball downloads after the fact, we are already in trouble, so I can stomach that. The release_tag is at least a manual input, good enough.

.github/workflows/release-flathub.yml

.github/workflows/release.yml

martinpitt · 2026-01-08T09:15:29Z

.github/workflows/update-guide.yml

@@ -0,0 +1,72 @@
+name: Update guide from release


Splitting this out and re-running manually is okay for me.

.github/workflows/update-guide.yml

Venefilyn · 2026-01-09T12:55:31Z

@martinpitt I removed the dependency in favor of a composable action ourselves (just to reduce duplication, but I can move it to steps if wanted)

Can see run here, guide succeeds as I had commented out the git push there for this run, don't think it would succeed but didn't wanna risk it
https://github.com/Venefilyn/cockpit/actions/runs/20852299144

martinpitt · 2026-01-12T06:44:41Z

.github/workflows/release-flathub.yml

    environment: flathub
    env:
-      COCKPITUOUS_TOKEN: ${{ secrets.COCKPITUOUS_TOKEN }}
+      COCKPITUOUS_TOKEN: ${{ secrets.COCKPITUOUS_RELEASE_TOKEN }}


The repo privilege is too much, sorry. This token has leaked before. It's absodefinitively not necessary to have full control over all of cockpit-project's repositories just to create a PR in a foreign one. Personal access tokens are just not the right tool for this kind of action, and if GitHub makes it so difficult to create a foreign PR, then so be it -- it's just three clicks every two weeks, it's really not worth spending so much effort on that.

@martinpitt this is a separate token though that should only be used within the workflow. Given GitHub is good at hiding secrets I don't see how we could leak it?

You say it's 3 clicks but we are quite bad at doing it anyway, which is why I've been pushing on this

I feel like this has to move into a workflow on the flathub repo. That has enough privileges with the default GitHub token to create a PR.

i.e. the on: push trigger feels right? On the cockpit.git side we push the branch, on the flathub repo side it creates/updates the PR?

I don't think we can, it still requires permissions to be able to take branches or tags from other repos. Nor do I know how to make the workflow trigger if we have an update - we could use their update checker thing but that solves the version updates but leaves the version changelog unchanged.

We can discuss this in another PR though, for low left it as it was

martinpitt · 2026-01-12T06:57:56Z

@Venefilyn I resolved a few of my previous review threads, but some are still relevant. ~~This also still uses robinraju/release-downloader~~ update: the third commit reworks this. Can you squash this? Also, the high-priv cockpituous token needs to go.

But honestly: this makes the release workflow a lot more complicated (over 200 lines!), and harder to track/review/understand.

Venefilyn · 2026-01-13T12:57:47Z

Also, the high-priv cockpituous token needs to go.

Answered in the thread

But honestly: this makes the release workflow a lot more complicated (over 200 lines!), and harder to track/review/understand.

Sure does introduce more lines.. which I'm also a bit frustrated with. The composite action I can get rid of and instead use the steps in it within each workflow itself if that helps reduce complexity. I figured that it reduces complexion for just going over the workflow in general as it's a fairly nice wrapper.

Most of the time we'd still only care about executing the release workflow through a tag, or by triggering each step manually

martinpitt · 2026-01-23T09:13:52Z

@Venefilyn If we do this restructuring, then the get-release-assets composite action is right, otherwise it would be a lot of duplication. My pain is more about having to do all this stuff in the first place -- the information is right there in the primary release workflow, and it's a lot of bureaucracy to move it around. And at least the node-cache workflow should better stay where it is. Otherwise, there are still the threads above, plus the squashing.

My honest opinion is: "this is a waste of time and unnecessary debugging hell, let's forget about it", but as I said I can be talked into splitting out the flathub workflow. I would just suggest to not also try to fix the flathub PR/cockpituous token issue in this PR, it's getting unwieldy (and that problem needs a wholly different approach IMHO)

martinpitt

See above, forgot to set the status so that it drops from my review list.

Makes it possible to execute each step manually without being dependent on the other. Removes a previous dependency in favor of a curl wrapper that gets the cockpit tarball release and verifies it against a checksum if available. If checksum is not available it is still provided to flathub release by taking the checksum from the downloaded tarball. Signed-off-by: Freya Gustavsson <freya@venefilyn.se>

Venefilyn · 2026-02-05T13:43:29Z

@Venefilyn If we do this restructuring, then the get-release-assets composite action is right, otherwise it would be a lot of duplication. My pain is more about having to do all this stuff in the first place -- the information is right there in the primary release workflow, and it's a lot of bureaucracy to move it around. And at least the node-cache workflow should better stay where it is. Otherwise, there are still the threads above, plus the squashing.

Squashed!

My honest opinion is: "this is a waste of time and unnecessary debugging hell, let's forget about it", but as I said I can be talked into splitting out the flathub workflow. I would just suggest to not also try to fix the flathub PR/cockpituous token issue in this PR, it's getting unwieldy (and that problem needs a wholly different approach IMHO)

Removed secrets.COCKPITUOUS_TOKEN_RELEASE. The flathub PR now works like it did before. To me it makes debugging easier. We still see where things failed and we can run it individually to experiment or work things out etc.

Only issue I have is that it can be difficult to parse.

Venefilyn added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Nov 27, 2025

Venefilyn changed the title ~~release/split release workflow~~ ci: Revamp release workflow Nov 27, 2025

Venefilyn mentioned this pull request Nov 27, 2025

flathub: Release token for flathub PR creation #22594

Closed

Venefilyn requested a review from jelly November 27, 2025 23:23

Venefilyn added jira sync2jira integration for GH issues. Creates a downstream Jira issue to sync to. and removed jira sync2jira integration for GH issues. Creates a downstream Jira issue to sync to. labels Dec 3, 2025

jelly reviewed Dec 16, 2025

View reviewed changes

martinpitt requested changes Jan 8, 2026

View reviewed changes

martinpitt added the blocked Don't land until something else happens first (see task list) label Jan 8, 2026

Venefilyn added blocked Don't land until something else happens first (see task list) and removed blocked Don't land until something else happens first (see task list) labels Jan 9, 2026

Venefilyn force-pushed the release/split-release-workflow branch from 90d6d31 to 3e56bc7 Compare January 9, 2026 12:53

Venefilyn removed the blocked Don't land until something else happens first (see task list) label Jan 9, 2026

Venefilyn requested a review from martinpitt January 9, 2026 12:54

martinpitt reviewed Jan 12, 2026

View reviewed changes

Venefilyn requested a review from martinpitt January 21, 2026 12:33

martinpitt requested changes Jan 23, 2026

View reviewed changes

Venefilyn force-pushed the release/split-release-workflow branch from 3e56bc7 to c0bd225 Compare February 5, 2026 13:40

Venefilyn requested a review from martinpitt February 5, 2026 13:40

Venefilyn force-pushed the release/split-release-workflow branch from c0bd225 to 251a314 Compare February 5, 2026 13:41

Conversation

Venefilyn commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jelly left a comment

Choose a reason for hiding this comment

Uh oh!

Venefilyn commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinpitt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Venefilyn commented Jan 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinpitt commented Jan 12, 2026

Uh oh!

Venefilyn commented Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinpitt commented Jan 23, 2026

Uh oh!

martinpitt left a comment

Choose a reason for hiding this comment

Uh oh!

Venefilyn commented Feb 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Venefilyn commented Nov 27, 2025 •

edited

Loading

Venefilyn commented Dec 16, 2025 •

edited

Loading

Venefilyn commented Jan 13, 2026 •

edited

Loading