feat: Enable import & extend, nightly schedule

kanidm / kanidm_ppa_automation

The magic that makes kanidm/kanidm_ppa work

Mozilla Public License 2.0

0 stars 1 forks source link

feat: Enable import & extend, nightly schedule #5

Open jinnatar opened 1 month ago

jinnatar commented 1 month ago

Primarily:

Enable nightly scheduled runs so that it does what it says on the tin.
Enable importing the current mirror as the basis of runs so that nightly runs don't drop stable.

Also:

Fixes #6 portion where kanidm_ppa.list has the wrong key suffix.

yaleman commented 1 month ago

Fun thing with GHA, while I think about it - if there's no changes for "60 consecutive days" they disable the actions runners so we need to periodically touch something in THIS repo to keep the cron job working, so might be worth adding a "push a touched file" step somewhere.

jinnatar commented 1 month ago

There's some other fundamental issues here as well:

This would work as written, BUT if any change is merged to main afterwards, the import of previous stable will conflict with the new builds of the same stable.
I don't really think mutating the matrix all the time is a solution, so that leaves finding a different trigger for the stable matrix. Could be deployment but I don't have experience with that. Could be release, easier to deal with.
But in any case version dedupe needs to be a thing, probably by increasing debian_rev but then it has to be done in the main repo, very hard to increment downstream.

So as much as it pains me, we might be better off merging back into the main repo? 😑

yaleman commented 1 month ago

I don't see a huge issue merging most of it back into main - but we really need the automation to be outside main as much as possible (or very very specifically filter its execution)

jinnatar commented 1 month ago

If stable publishing only triggers on release then that would stay out of the way most of the time. That logic can be tested in this repo first. For nightly, we could only trigger on schedule normally, but also on PRs that have a specific tag to allow useful PRs against the automation itself. That way nothing triggers on push i.e. merge, or on most PRs. Would that work? It's probably the the sweet spot between competing issues of:

Does not die on it's own every 60 days. (rules out separate automation repo)
Doesn't hold the automation code in a repo that has so much binary history it's unusable. (rules out automation + mirror in the same repo)
Has organic triggers to build stable. (Probably only possible in the main repo)
Allows manual jiggery pokery if things go horribly wrong (modifying repo state in kanidm_ppa if some rogue GenAI takes over GHA and trashes it. Or the automation fails in unexpected ways.)