| 20 Mar 2024 |
 Philip Taron (UTC-8) | How so? It' | 23:15:04 |
| Philip Taron (UTC-8) | * How so? | 23:15:09 |
 infinisil | Oh yeah should be fine, we can just do full nix-build's then and not worry about fetching pre-built paths | 23:15:41 |
| Philip Taron (UTC-8) | Yeah. | 23:15:46 |
| Philip Taron (UTC-8) | People can pay for it. | 23:16:08 |
| Philip Taron (UTC-8) | CI doesn't want to. | 23:16:14 |
| infinisil | Haha yes | 23:16:33 |
| infinisil | Okay so, I guess the next thing to do is to have some automated release process that creates the artifacts, I'll look into that | 23:17:02 |
| Philip Taron (UTC-8) | Take a look at this repo: https://github.com/sorairolake/qrtool | 23:17:39 |
| Philip Taron (UTC-8) | I see that it's being released by github-actions, which is what we want, I think. | 23:19:20 |
| infinisil | Yeah sounds good, it's using https://github.com/softprops/action-gh-release | 23:19:54 |
|  hacker1024 joined the room. | 23:20:05 |
| infinisil | Although this would involve having to manually push tags, not a fan of that | 23:20:48 |
| infinisil | Would be nicer if it would automatically do a weekly PR, which when merged creates a release | 23:21:01 |
| infinisil | Or so | 23:21:05 |
| Philip Taron (UTC-8) | That's totally possible, and since we'll need a machine account anyway to not get stalled on automated PRs, it can absolutely push a tag, I would think. | 23:22:09 |
| infinisil | The automated update PRs (like https://github.com/NixOS/nixpkgs-check-by-name/pull/14) don't need any special privileges, since it's just a PR | 23:23:13 |
| infinisil | A tag would need more permissions | 23:23:18 |
| infinisil | We could do something like "For every master push, check if its version number increased, if yes, create a release" | 23:23:47 |
| Philip Taron (UTC-8) | Having that in the git metadata is quite nice. | 23:24:09 |
| Philip Taron (UTC-8) | Sure, it's more permissions, but it's really nice. | 23:24:28 |
| infinisil | I guess we really don't need a separate machine account for the automated releases | 23:25:43 |
| infinisil | We can just give the github action permission for that | 23:26:01 |
| infinisil | The separate machine account workaround is only needed to trigger workflows from PRs triggered by workflows | 23:26:30 |
| Philip Taron (UTC-8) | In reply to @infinisil:matrix.org
Would be nicer if it would automatically do a weekly PR, which when merged creates a release
The separate machine account workaround is only needed to trigger workflows from PRs triggered by workflows
I'm getting confused.
We do want an automatic-ish update of dependencies. ✅ -- but with an explicit human in the loop hitting the merge button.
We do want an automatic-ish release process. ✅ -- but with an explicit human in the loop to move from draft to public.
So, we want a separate machine account, so that the CI all fits together, and doesn't get wedged like #14 did.
Right?
| 23:34:24 |
| infinisil | Ahh right! | 23:34:53 |
| infinisil | I'm getting confused too 😅 | 23:34:59 |
| infinisil | Philip Taron (UTC-8): Concretely, how about this:
- The version gets bumped (probably in
Cargo.toml) with a PR
- This can either happen manually if somebody remembers
- Otherwise a bot will automatically do that with a PR that just does the version bump
- A separate workflow, triggered on main branch pushes, takes care to do the release whenever the version gets bumped
| 23:39:22 |
| infinisil | * Philip Taron (UTC-8): Concretely, how about this:
-
The version gets bumped (probably in Cargo.toml) with a PR
- This can either happen manually if somebody remembers
- Otherwise a bot will automatically do that with a PR that just does the version bump
-
A separate workflow, triggered on main branch pushes, takes care to do the release whenever the version gets bumped
| 23:39:39 |
| infinisil | For 1. we need the separate machine account, but it doesn't need any permissions because it just creates a PR. For 2. we don't need a separate machine account and can just give the workflow the permission to push a tag/release | 23:40:37 |
