Our great sponsors
-
-
Personally with Github Actions, I do find myself pushing 2, 3 or 4 times just getting the pipeline working because I always mess something up, either I've messed up a command or the environment isn't what I expected etc. There's act[0] for github which I should use more often to solve this, but I usually forget
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Nice! I made a similar tool a while back:
It's a pair of really simple Python scripts: cirunn.py for executing locally, an ciorder.py to execute stuff via ssh on another host (useful for projects that are too big for the laptop).
The difficulty I found here is deciding what the user actually means to run: is it more like `make test`, where the current state of the working directory is tested, or more like the CI pipeline, where only committed changes are tested?
For the sake of practicality, the local script tests uncommitted changes, and the remote one checks the last commit.
-
IMO this is where having access to native Linux, WSL 2 or a VM along with using Docker helps a lot.
Personally I write the bulk of my CI scripts as shell scripts and put them into a runnable file included in the project. This way I can run CI scripts locally so I can test the work flow on my machine. It's also handy in case CI is down you can still test and deploy your code. Lastly it lets you easily jump between CI providers since a majority of your logic is in a generic shell script.
For example in my CI specific files I typically only call `./run ci:install-deps && ./run ci:test`. Then there's a tiny bit of boiler plate in each CI provider's yml file to handle specific things for that provider.
Since my app is running in Docker most of the heavy duty dependencies are all contained there. The dependencies I install directly in CI end up being things like installing shellcheck and helper scripts for CI (like tiny scripts that let you wait until a process is ready). Having WSL 2 is nice here because these are very small tools that I want locally installed anyways, but if you don't run Ubuntu locally you can do this in a VM.
A working example of this is here: https://github.com/nickjj/docker-flask-example
Check out the run script for "ci:" functions and the GH Actions yml file. This same strategy applies to GitLab or any other CI provider too.
-
earthly
Super simple build framework with fast, repeatable builds and an instantly familiar syntax – like Dockerfile and Makefile had a baby.
How does this differ from Earthly? https://github.com/earthly/earthly
Earthly lets you abstract anything you do inside a container into an Earthfile, that runs locally on a dev's machine, but also in any CI, making CI scripts more portable. However, testing other CI-specific things before committing, such as GitLab rules dictating when jobs actually run, remain unsolved. But they also remain unsolved with this glci solution, right?
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
