It seems to be a lighweight project. It's perfect for small projects!

That's great to have such simple deployment. Maybe one for rust with such a script or command could be great too.

Or a bash script :)

CI files should be kept simple and only start a command for each task. The local and CI tasks will remain the same: build, test, or dependency installation are the common cases.

At some point, environment variables become necessary but the complexity should remain O(1). It should not be adjusted based on features.

Installing binaries instead of sources then compiling. It can be especially useful for CI.

Github Worflow trigger cheatsheet

Feedbacks about the open-source build tool Bazel, backend by Google.

CI looks like build systems. If you push a CI system or a build systems too far, they seem to be the same as what they are doing.
The thing that bugs me about modern CI systems is that I inevitably feel like I'm reinventing a build system and fragmenting build system logic.

So going beyond the section title: CI systems aren't too complex: they shouldn't need to exist. Your CI functionality should be an extension of the build system.

CI offerings like GitHub Actions and GitLab Pipelines are more products than platforms because they tightly couple an opinionated configuration mechanism (YAML files) and web UI (and corresponding APIs) on top of a theoretically generic remote execute as a service offering.

I'm convinced that building what I'd like to see is not a question of if it can be done but whether we should and who will do it.

In my ideal world there exists a single remote code execution as a service platform purpose built for servicing both near real time and batch/delayed execution. It is probably tailored towards supporting software development, as those domain specific features set it apart from generic compute as a service tools like Kubernetes, Lambda, and others. But something more generic could potentially work.

Conclusion:

If I could snap my fingers and move industry's discrete build, CI, and maybe batch execute (e.g. data pipelines) ahead 10 years, I would:

1. Take Mozilla's Taskcluster and its best-in-class specialized remote execute as a service platform.
2. Add support for a real-time, synchronous execute API (like Bazel's remote execute API) to supplement the existing batch/asynchronous functionality.
3. Define Starlark dialects so you define CI/release like primitives in build tools like Bazel. (You could also do YAML here. But if your configuration files devolve into DSL, just use a real programming language already.)
4. Teach build tools like Bazel to work better when units of work that can take minutes or even hours to run (a synchronous/online driver model such as classically employed by build systems isn't appropriate for long-running test, release, or say data pipelines).
5. Throw a polished web UI for platform interaction, result reporting, etc on top.
6. Release it to the world.

Why are lockfiles critical for supply chain ?

You are protected from a silent update of the package at the same version.

The articles provide a table with the different related commands 👍‍

Un projet dédié à été crée afin de monitorer le CI de plusieurs projets: https://github.com/mvisonneau/gitlab-ci-pipelines-exporter

Le reste de l'article explique comment faire :)

• Shallow cloning avec GIT_DEPTH=1
• Cache
• Artefacts
• Retry
• Évitez les déploiements depuis les forks
• Sécurité - Lockez vos versions pour rendre vos builds reproductibles
• Sécurité - Services intégrés