I just started using GitHub Actions for a personal project, and as you do, I trawled HN for opinions on how to use it.
At first I built a workflow out of steps published on GitHub. Use ilammy/mms-dev-cmd, lukka/get-cmake, lukka/run-vcpkg, all to build a project with CMake for Windows targets. Of course I referred to actions by SHA like you should
But one comment stuck with me. Something like, “You should just run your own code on GitHub Actions, rather than piecing it together from publicly available actions.” That made a lot of sense. I ended up writing a driver program for my personal project’s CI builds. One job builds the driver program, and then the next job runs the driver program to do the entire build.
I wouldn’t do this if I were getting paid for it… it’s more time-consuming. But it means that I am only minimally tied to GitHub actions. I can run the build driver from my own computer easily enough.
> I ended up writing a driver program for my personal project’s CI builds. One job builds the driver program, and then the next job runs the driver program to do the entire build.
Yes things like that have been discussed before on HN. Also for example use a justfile (or something similar) and then call that from inside the Action to reduce vendor lock-in.
I use Actions merely as a way to trigger a custom Webhook. Then I do everything on the server that receives the hook with my own code. I hate YAML that much.
That's effectively what we are doing. The webhook receives any "custom properties" you have defined on your repo, the ssh url, and critically, the name of the Action that was run. The receiving server can use all of this to select the appropriate pipeline. Our build server is not containerized.
Sounds like you are assuming that I have a server always running for this stuff? That assumption is wrong. I don’t want to run CI servers. If I had servers always running, I would install Jenkins on them and the problem would be solved.
If you are doing deployments, actions etc does exactly that. Run pure bash commands or whatever.
If you want it for other purposes, you essentially want to run a "server" application but don't want to manage a server. Just use serverless? Write a JS function (or some other languages) and the platform will run it when the event triggers.
We do, but you can only trigger those on predefined events, and we want our release manager to be independent of any push or pull mechanisms on the repo. You can also run actions from the github web ui which makes them available even to non technical managers.
Our Action has a single step, it has an "if: false" declaration so it never runs, and no runners are engaged. This immediately completes and fires off a "workflow_job" webhook which triggers the build server to act.
At first I built a workflow out of steps published on GitHub. Use ilammy/mms-dev-cmd, lukka/get-cmake, lukka/run-vcpkg, all to build a project with CMake for Windows targets. Of course I referred to actions by SHA like you should
But one comment stuck with me. Something like, “You should just run your own code on GitHub Actions, rather than piecing it together from publicly available actions.” That made a lot of sense. I ended up writing a driver program for my personal project’s CI builds. One job builds the driver program, and then the next job runs the driver program to do the entire build.I wouldn’t do this if I were getting paid for it… it’s more time-consuming. But it means that I am only minimally tied to GitHub actions. I can run the build driver from my own computer easily enough.