zlacker

This might be an unpopular opinion but bundling CI/CD logic with the application code has been a huge blunder IME. If you're adding CI/CD for the first time to a brownfield project you're looking at dozens of minor YAML tweaks to master directly (or a bunch of rubber-stamped PRs).

Why can't I have a separate interface where I just say "build this Github project, and put the content on this on-prem server/kube cluster/VM/whatever."

>>pc86+(OP)
If I'm doing something complex with GitHub Actions I like to work in a branch, iterate with a bunch of messy tweak commits and then squash-merge into main once I've got it working exactly right.

Another trick that works well is putting GitHub Actions in an entirely separate repository. There's nothing to stop actions in one repo from checking out code from another - I use that trick quite frequently.

You do have to jump through a few extra hoops to set it up so that code in your actions repo starts running automatically on commits to your main repo, but you can do that with a small action in the main repo that triggers a build in the actions repo.

>>simonw+H6
Interesting approach. Do you mind sharing link with repos?

>>simonw+H6
These are both great tips, thank you!

>>xomodo+la
I don't have any at the moment where a commit to one triggers a build in another, but I have a bunch that run on a schedule, pull code from other repos and do stuff with it.

Best example of that is here: https://github.com/simonw/covid-19-datasette/blob/main/.gith...

>>pc86+(OP)
Who CICD's the CICD? It's turtles all the way up.

Testing a pipeline that depends on a merge to a branch, or a specific tag, is troublesome. Easier to just iterate in the mainline until you're ready.