Is any of this unique to GitHub Actions that does not happen on other cloud CI platforms?

embedding-shape 9 hours ago | parent | next [-]

The best CI platforms let you "Rebuild with SSH" or something similar, and instead of having the cycle of "change > commit > push > wait > see results" (when you're testing CI specific stuff, not iterating on Makefiles or whatever, assuming most of it is scripts you can run both locally and in CI), you get a URL to connect to while the job is running, so you can effectively ensure manually it works, then just copy-paste whatever you did to your local sources.

▲

palata 7 hours ago | parent | next [-]

I use that a lot with SourceHut: after a build fails, you have 10 minutes to SSH into the machine and debug from there. Also they have a very nice "edit manifest and run" feature that makes it easy to quickly test a change while debugging.

Are there other platforms allowing that? Genuinely interested.

▲

embedding-shape 7 hours ago | parent [-]

> after a build fails, you have 10 minutes to SSH into the machine and debug from there.

Ah, that's like 90% of the way there, just need to enable so the SSH endpoint is created at the beginning, rather than the end, so you could for example watch memory usage and stuff while the "real" job is running in the same instance.

But great to hear they let you have access to the runner at all, only that fact makes it a lot better than most CI services out there, creds to SourceHut.

	▲	palata 7 hours ago \| parent [-]
		> just need to enable so the SSH endpoint is created at the beginning Maybe it is, I've never tried :-). I don't see a reason why not, probably it is.

▲

cesarvarela 8 hours ago | parent | prev [-]

There are a couple of GitHub actions that let you do this.

▲

alfonsodev 7 hours ago | parent [-]

do you mean https://github.com/nektos/act or there is something else ?

	▲	efrecon 6 hours ago \| parent [-]
		No. Act is for running actions locally. What was mentioned is a way to insert an SSH step at some well-chosen point of a workflow so you can login at the runner and understand what is wrong and why it's not working. I have written one such thing, it relies on cloudflare free tunnels. https://github.com/efrecon/sshd-cloudflared. There are other solutions around to achieve more or less the same goal.

▲

gchamonlive 7 hours ago | parent | prev [-]

I designed a fairly complex test matrix with a lot of logic offloading to the control mechanisms Gitlab offers. You create job templates or base jobs that control the overall logic and extend them for each particular use case. I had varying degrees of success, and it's not a job for a Devs side quest, that means I think you need someone dedicated to explore, build and debug these pipelines, but for a CI tool it's very good.

Because you can extend and override jobs, you can create seams so that each piece of the pipeline is isolated and testable. This way there is very little that can go wrong in production that's the CI fault. And I think that's only possible because of the way that Gitlab models their jobs and stages.