Feature Request: actions/setup-clab step to install clab via Github Actions workflow

[bortok]

Besides being well aligned with prerequisites setup workflow of Github Actions, it would be nice to reduce issues encountered while deploying via a standard bash script, like hitting API limits when checking the latest version if there are multiple parallel jobs are installing clab simulteneously.

[steiler]

You can disable the versioncheck via an envitonment variable:
see: https://containerlab.dev/cmd/deploy/#clab_version_check

CLAB_VERSION_CHECK=disable

Would that suite your needs? What is are issues in your view?

[bortok]

First, clab binary has to be installed on a github actions runner instance, and this is where it fails with parallel jobs. Disabling version check might push out hitting API limit to run one or two more parallel job, but that is not much (although it looks like a good practice to use in CI/CD anyway).

One of the workarounds suggested was to use apt instead of the bash script to install. Although it would be fine just for the github actions workflow, it doesn't help if I want to let random users to run all CI/CD steps manually via a Makefile (my github actions are calling make underneath) - since I don't want to lock the Makefile to be just for Debian-based systems, and I also would like to avoid layers of complexity.

The standard bash installation script is doing a great job of installing clab via a Makefile if it is not on the system while launched manually. If paired with actions/setup-clab for the github actions, it would eliminate the need to lock into using Debian-based runners with for apt workaround.

See the Makefile example I'm using here: https://github.com/open-traffic-generator/otg-examples/blob/main/clab/ixia-c-b2b/Makefile and Github Actions workflow based on it here: https://github.com/open-traffic-generator/otg-examples/blob/main/.github/workflows/ci.yml

[hellt]

@bortok it looks like an action itself won't solve this, as the API limiting happens for these calls

curl curl -s https://api.github.com/repos/srl-labs/containerlab/releases/latest 

Can you please try to specify a particular clab version in your gh actions like this:

bash -c "$(curl -sL https://get.containerlab.dev)" -- -v 0.34.0

That way we shouldn't use this particular API endpoint and no throttling should occur. At the same time, your CI is guaranteed to use a desired version, which is typically a good practice, rather than downloading latest.

[bortok]

@hellt agree, specifying a version would be a proper way instead of latest. There are several way you could do version-specific install - the bash script like you suggested is one of them. But as something completely custom to containerlab, it lacks a chance to be tracked by dependabots. Do you know which approach could enable such dependency tracking? It is quite valuable to make sure a CI pipeline works with every new release of containerlab.

[hellt]

yes, for dependabot integration you need to either have an action, or a go.mod file with the imported clab package. That way dependabot will raise a PR indicating a new version number, but, ofc, you will have to change your CI pipelines accordingly