github-action-tester
Our great sponsors
| github-action-tester | test-ci-needs | |
|---|---|---|
| 1 | 1 | |
| 26 | - | |
| - | - | |
| 0.0 | - | |
| almost 4 years ago | - | |
| Shell | ||
| - | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
github-action-tester
-
GitHub Actions Limitations and Gotchas
To be honest I've always found the best approach with most of these systems is to checking your magic as shell-scripts inside your repository.
Then you're much much more portable. Want to run tests? Run ".ci/tests.sh", want to generate artifacts "make", or ".ci/build.sh".
All systems, be they github actions, jenkins, gitlab-runners, and everything else allow you to clone/update your repository and run something from within it. Which keeps things mostly portable.
I put together a simple github action a long time ago, but now of course I realize it is overkill:
https://github.com/skx/github-action-tester/
test-ci-needs
-
GitHub Actions Limitations and Gotchas
Sorry, it was with `only:changes` and `needs`. Take a look at this issue[0] and this pipeline[1]. I've failed to find the failure mode in the documentation, so I suppose it may have been fixed since then - but we've developed an in-house workaround in the meantime that I'd trust a lot more than anything coming out from Gitlab.
--------
> A monorepo isn't "all but the most simple use-cases", it's usually a fairly complex usecase, and Gitlab have a myriad of ways to make monorepo CI easier - dynamic pipelines, remote triggers, includes, etc.
And every single feature you've mentioned here has a bug when combined with something else. That's the problem with Gitlab CI: everything works in isolation, but nothing composes properly.
Take includes: they don't work with anchors, so you couldn't have a generic template rules in the "main" file getting reused in the included files. This makes sense though! Anchors are a yaml feature. So gitlab added their own pseudo-anchors, called `extends`. You'd assume a smart, context-aware merge to happen, but no! Gitlab decided to go with a dumb object merge. Because the `script` step is a list of string, if both the parent and the child specify a `script`, only the child's will be used! Gitlab has a `before_script` step which can be used to workaround the issue for single levels of inheritance, but anything more complex ends up in a dead end. This feels like a feature that's been bolted on without any sort of design work.
[0]: https://gitlab.com/gitlab-org/gitlab/-/issues/31310
[1]: https://gitlab.com/ensc/test-ci-needs/-/pipelines/78713602
What are some alternatives?
turnstyle - 🎟️A GitHub Action for serializing workflow runs
act - Run your GitHub Actions locally 🚀
actions-runner-controller - Kubernetes controller for GitHub Actions self-hosted runners
xmonad - The core of xmonad, a small but functional ICCCM-compliant tiling window manager
gitlab
actions-runner-
jenkins-std-lib - Bringing the Zen of Python to Jenkins.
roadmap - GitHub public roadmap