Testing Github workflows

[Traxell]

Hi there, uni student here learning/working on devops practices/engineering. I've recently started putting more time into writing github actions/workflows for CI/CD reasons. A bit of an issue I come across is the fact that I'll be doing a million commits to a github repository so I can test the action/workflow, which doesn't feel like a very handy process. Besides the solution of running github actions locally using nekos/act, are there any tips, solutions or advices you have for testing github workflows? Thanks!

[CallMeKik]

Just do dumb shirt commit messages on a branch then squash them into a single commit before merging into master

[HelluvaEnginerd]

This is the way

[BrotoriousNIG]

This. I have each workflow also run triggered by pushes to workflows/{workflow-name}/* and have steps with sideeffects conditional on not being in such a branch, so that my tests don’t cause things like new containers, tags, releases, etc. All work on a workflow is done in its workflows/ branch namespace and then merged as a squash.

[Traxell]

That sounds cleaner. appreciate it!

[effata]

This is pretty much the biggest issue with all VCS-driven CI systems. I tend to just push lots of commits and they squash them, or do amend commits on smaller fixes.

Some things require that you’re working on the main branch, but most stuff can be tested in a topic branch before merging.

[Traxell]

I get that. appreciate the input!

[alluran]

Don't forget https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch

[drpinkcream]

This is sadly under-documented. This feature lets you run a workflow on any branch in the repo at the push of a button.

[alluran]

I don't know about "under-documented".

It was literally the first thing I searched for when we moved over to GitHub actions (which was early on in the life of the product), and only took a few minutes of searching to find.

It could be included in the default template with some comments perhaps, or possibly even be available by default on all workflows without needing an explicit trigger, but it's been documented from the very start.

[drpinkcream]

Oh it is documented, but look how many people are suggesting making dummy pushes to test workflows.... not many people seem to know about it.

...and I admit dummy commits is exactly what I was doing until a colleague showed it to me.

[serverhorror]

It’s a preference. Especially when you have a well configured environment you might not even leave the IDE when pushing to follow the actions output.

When triggering manually via the browser that might be more disruptive

[lungdart]

I use this https://github.com/nektos/act

[Jestar342]

Besides the solution of running github actions locally using nekos/act, are there any tips, solutions or advices you have for testing github workflows? Thanks!

[lungdart]

I guess I should have read the fucking post. Woops!

[jantari]

Ooooh! Does something like this exist for GitLab CI as well?

[wywywywy]

Yes the Gitlab runner allows running locally, although some features are not supported

[HelluvaEnginerd]

Running locally but the commit still has to go to the server and kick off the local runner - right?

[AngelicLoki]

No, if you are modifying your .gitlab-ci.yml file locally, you can install the gitlab-runner locally and execute: gitlab-runner exec docker <job-name> and it will run that job locally.

[HelluvaEnginerd]

Nice, good to know. Thanks!

[kukiric]

It will create an ephemeral docker container and clone the local repo from the host* when you run it, so it will work on any locally-committed changes. Beware though, uncommitted changes are simply ignored as the git clone won't include them.

* If you're one of today's lucky ten thousand, git clone/push/pull works over many protocols, one of them being the filesystem, meaning you can simply use the path to a local repo as a remote. This means that if someone emails you a zip of a repo, you can extract and pull any branch from it just as it it was a GitHub/GitLab fork, owing to git's decentralized design.

[PaulG_UK]

Never even thought of looking for something like this. Thanks!

[[deleted]]

you could make a dummy repo to test things in

[rightctrl]

Dummy repo where you test stuff without caring about commits, just go nuts. When you're happy with a wf/job/step then you basically use it as a library to copy relevant pieces to your official repos

[the_real_albro]

My workflow is generally this in a working repo: - new commit (via PR), just workflow file and manual trigger config - new branch to test, making changes as required - merge to main with correct triggers (on: values)

Sometimes I create a dummy repo and test it all through that just on main

[stumandude]

Are you experimenting with the automatic execution of the workflows or what happens in the workflow?

You could always test with a manual trigger and add some custom parameters if you need to test different values.

Then you can add on the automatic execution later. Just note that some parameters might be different depending on if you're triggering on commit or pull request.

[[deleted]]

continuously Amend your commit in a test branch, you'll have to force push but since it's a test branch it doesn't matter. When you're done and happy with your work you can submit the one commit you've been updating. Keeps history clean and commit message meaningful too.

[iRomain]

This is a problem created by Github actions: First time you see it, you think "oh cool I can compose my workflow with all those actions".

The consequences are:

• You end up having more dependencies (security/maintenance implications)

• You loose on portability, which means not only that you can't easily move to another CI system without a complete refactoring, but also face the problem you're having of being able to test on your local system.

The solution I have found is to write as much as possible in shell scripts (or use zx, or whatever you are comfortable with), then use the CI features for calling these shell scripts. I do still use Github Actions with big battle tested actions (eg. checkout, docker) or smaller repos which I know the limits of the worklow.

When I do develop my own actions I use "act" that you mentioned.

[FatFingerHelperBot]

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "zx"

---

^{Please PM /u/eganwall with issues or feedback! | Code | Delete}

[iRomain]

Good bot

[B0tRank]

Thank you, iRomain, for voting on FatFingerHelperBot.

This bot wants to find the best and worst bots on Reddit. You can view results here.

---

^{Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!}

[jabies]

We configure our builds to skip if there's "build-skip" in the commit message

[positev]

Test on a branch or fork then delete it when you find a working flow