What would be really nice is to have some sort of standard to express the CI steps in a common format. That way I could import my CI config into any new CI system and I should be ready to go right from the start.
Cirrus CI kind of have a way to do this. They publish a CLI tool that lets you run jobs locally. The same tool can be used in other CI services to run jobs there. So you can define your jobs in the Cirrus YAML format then run that on whatever provider you want. They have a bunch of examples on this page. https://github.com/cirruslabs/cirrus-cli/blob/master/INSTALL.md#github-actions
That’s hard for a lot of systems because they have prepackaged steps. For GitHub Actions, for example, a lot of the packaged jobs use Node.is to drive complicated operations. You might be able to expand these into a sequence of shell commands (at least in the simple case for a particular set of inputs) but that wouldn’t work in the complex case. Even the checkout task is fairly complicated since it has a bunch of options for managing credentials used to check out submodules and so on.
I’m reading it as “we’ll do what’s best for the project, regardless if that’s 1 or 15 providers”. At one point in time, it seemed best to have redundancy. But the world is constantly changing and in the future it might be best to have only a single provider. At this point in time, however, GH actions seems to suit the projects needs quite well.
I have been a heavy user of GitHub Actions over the last few years. Yaml configuration can be pretty rancid, but I still feel most of my challenges can be solved by hacking some bash/python/JS in (current jobs are using all 3 for configuration) and by using community packages. I often want to chuck the yaml in the trash and use a real language to configure everything. Why they didn’t go with a TypeScript file is beyond me.
My wish list contains GPU support and M1 runners (the latter we’re going to solve by my boss buying a mac mini). Some new integration tests I’m adding are going to be 14h per commit 🫣
I’ve also been using GitHub Actions a lot, in particular with ChristopherHX’s reimplementation of the runner in go. This makes it easy to use GitHub Actions to drive a large range of platforms and architectures that aren’t officially supported.
I am also a heavy user of github actions but am considering switching to sourcehut just because they let you SSH into the hosts if a run fails. It takes so long to develop solid CI pipelines on github because you have to commit, push, and wait for the job to be picked up, initialized, and run before you can see whether it fails. After a decade developing software I really do think iteration time is the strongest single predictor of how long something will take to implement.
SSH into a failing build is such a lifesaver. I use it all the time on sourcehut, and I can’t imagine why anyone would launch a CI platform that doesn’t have that feature. The feedback loop without it is awful.
I echo a lot of this at work. We were heavily based on Travis until the 2021 thingy, then moved from that to CircleCI, then eventually got mostly pushed to run on internal CI services (yay bash scripts on jenkins?).
Killer app would be an adapter that allows you to just run a script :tm: on any of the free service providers.
What would be really nice is to have some sort of standard to express the CI steps in a common format. That way I could import my CI config into any new CI system and I should be ready to go right from the start.
Cirrus CI kind of have a way to do this. They publish a CLI tool that lets you run jobs locally. The same tool can be used in other CI services to run jobs there. So you can define your jobs in the Cirrus YAML format then run that on whatever provider you want. They have a bunch of examples on this page. https://github.com/cirruslabs/cirrus-cli/blob/master/INSTALL.md#github-actions
That’s hard for a lot of systems because they have prepackaged steps. For GitHub Actions, for example, a lot of the packaged jobs use Node.is to drive complicated operations. You might be able to expand these into a sequence of shell commands (at least in the simple case for a particular set of inputs) but that wouldn’t work in the complex case. Even the checkout task is fairly complicated since it has a bunch of options for managing credentials used to check out submodules and so on.
I find it sad that something as central and infrastructure-critical, for the whole web, as curl, has to run on free/very cheap plans :(
Hmm.
GH Actions is one of 5 CI providers.
I’m reading it as “we’ll do what’s best for the project, regardless if that’s 1 or 15 providers”. At one point in time, it seemed best to have redundancy. But the world is constantly changing and in the future it might be best to have only a single provider. At this point in time, however, GH actions seems to suit the projects needs quite well.
I have been a heavy user of GitHub Actions over the last few years. Yaml configuration can be pretty rancid, but I still feel most of my challenges can be solved by hacking some bash/python/JS in (current jobs are using all 3 for configuration) and by using community packages. I often want to chuck the yaml in the trash and use a real language to configure everything. Why they didn’t go with a TypeScript file is beyond me.
My wish list contains GPU support and M1 runners (the latter we’re going to solve by my boss buying a mac mini). Some new integration tests I’m adding are going to be 14h per commit 🫣
I’ve also been using GitHub Actions a lot, in particular with ChristopherHX’s reimplementation of the runner in go. This makes it easy to use GitHub Actions to drive a large range of platforms and architectures that aren’t officially supported.
I am also a heavy user of github actions but am considering switching to sourcehut just because they let you SSH into the hosts if a run fails. It takes so long to develop solid CI pipelines on github because you have to commit, push, and wait for the job to be picked up, initialized, and run before you can see whether it fails. After a decade developing software I really do think iteration time is the strongest single predictor of how long something will take to implement.
SSH into a failing build is such a lifesaver. I use it all the time on sourcehut, and I can’t imagine why anyone would launch a CI platform that doesn’t have that feature. The feedback loop without it is awful.
By all means not a perfect solution, but https://github.com/nektos/act can help in these cases where you want to run the pipeline locally.
I echo a lot of this at work. We were heavily based on Travis until the 2021 thingy, then moved from that to CircleCI, then eventually got mostly pushed to run on internal CI services (yay bash scripts on jenkins?).
Killer app would be an adapter that allows you to just run a script :tm: on any of the free service providers.