Fast, portable and reliable dependency analysis for any codebase. Supports license & vulnerability scanning for large monoliths. Language-agnostic; integrates with 20+ build systems.
Notice that these two runs are happening for the exact same commit sha, and the times for each step are close except for the time to run integration tests. On comparing the logs I discovered that they were running different versions of Nix, and that a newer one had been released on 3/11. Nothing in the release notes jumped out at me as a thing that would slow things down though. On this branch I explicitly set nix to 2.20.5, the previous release, and found that the time to run integration tests went back to normal.
I also found that we are using a custom nix build script. I tried using cachix/install-nix action since it had been a while since the bug that lead to us using a custom script had happened. It seems to work OK. It installs an older version of Nix, but I don't really see a reason we have to be on latest and I think the faster build times are worth it for now.
This problem may pop up again in the future, but likely only when we explicitly update cachix/install-nix so it will hopefully be less surprising.
Acceptance criteria
Time to run integration tests returns to normal.
The install nix step doesn't have an error like the group 'nixbld' specified in 'build-users-group' does not exist which is what the custom script tried to avoid.
Testing plan
Look at the integration test logs as well as timing and see that it is better than current master.
Risks
This may happen again. I don't have time today try to see if there's a way to speed up Nix 2.21. Still, if the problem reappears it should be at a time when we're actively changing the Nix parts of our CI pipeline rather than randomly like now.
Checklist
[x] I added tests for this PR's change (or explained in the PR description why tests don't make sense).
[x] If this PR introduced a user-visible change, I added documentation into docs/.
[x] If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
[x] If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
[x] If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
[x] If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.
Overview
Starting on 3/12 our integration tests went from taking < 20 minutes to taking over 30. Mar 11: https://github.com/fossas/fossa-cli/actions/runs/8243832338 Mar 12: https://github.com/fossas/fossa-cli/actions/runs/8227908631
Notice that these two runs are happening for the exact same commit sha, and the times for each step are close except for the time to run integration tests. On comparing the logs I discovered that they were running different versions of Nix, and that a newer one had been released on 3/11. Nothing in the release notes jumped out at me as a thing that would slow things down though. On this branch I explicitly set nix to 2.20.5, the previous release, and found that the time to run integration tests went back to normal.
I also found that we are using a custom nix build script. I tried using
cachix/install-nixaction since it had been a while since the bug that lead to us using a custom script had happened. It seems to work OK. It installs an older version of Nix, but I don't really see a reason we have to be on latest and I think the faster build times are worth it for now.This problem may pop up again in the future, but likely only when we explicitly update
cachix/install-nixso it will hopefully be less surprising.Acceptance criteria
the group 'nixbld' specified in 'build-users-group' does not existwhich is what the custom script tried to avoid.Testing plan
Look at the integration test logs as well as timing and see that it is better than current master.
Risks
This may happen again. I don't have time today try to see if there's a way to speed up Nix 2.21. Still, if the problem reappears it should be at a time when we're actively changing the Nix parts of our CI pipeline rather than randomly like now.
Checklist
docs/.docs/README.msand gave consideration to how discoverable or not my documentation is.Changelog.md. If this PR did not mark a release, I added my changes into an# Unreleasedsection at the top..fossa.ymlorfossa-deps.{json.yml}, I updateddocs/references/files/*.schema.jsonAND I have updated example files used byfossa initcommand. You may also need to update these if you have added/removed new dependency type (e.g.pip) or analysis target type (e.g.poetry).docs/references/subcommands/<subcommand>.md.