slsa-framework / slsa-verifier

Verify provenance from SLSA compliant builders
Apache License 2.0
231 stars 50 forks source link

feat(action): Node20, multi-OS/Arch, caching, tests, and Workflows #807

Closed IAreKyleW00t closed 1 month ago

IAreKyleW00t commented 2 months ago

Hi!

This PR relates to the discussion from #806 regarding the Node16 deprecation notice. During this we talked about adding support for multiple OSes, as well as addressing the caching logic. There was quite a bit of change required to make this work, so I took the liberty of updating others files to better reflect most TypeScript Actions now-a-days and adding many more test cases.

There are no breaking changes. Everything will continue to work without change for existing users, just with a few enhancements. I was actually able to plug in my fork on some personal projects without any changes.

I hope I'm not overstepping with a PR of this size but I wanted to give a "complete package" - I had some fun fleshing this out so I may have gone a bit overboard too haha 😇 Happy to make any adjustments

Action CI: https://github.com/IAreKyleW00t/slsa-verifier/actions/runs/10911993495

Test PR w/ bad dist/ changes: https://github.com/IAreKyleW00t/slsa-verifier/actions/runs/10911978180 Update dist/ with Workflow: https://github.com/IAreKyleW00t/slsa-verifier/actions/runs/10911989035 Re-test PR: https://github.com/IAreKyleW00t/slsa-verifier/actions/runs/10912006068

Node20

Obviously this is on Node20, but wanted to make sure it was called out that the actions/installer/.node-version file is what defines the version to be used by CI and developer locals.

README updates

The README has been updated with more information on the Action itself. Since users are already directed there from the main README, I figured it would be worth updating this to include details like Inputs, Outputs, usage, and even Developer guides.

Multi-OS and Arch support

As mentioned, since the main SLSA Verifier project builds binaries for Linux, macOS, and Windows, I thought it would be good to have this action cover this too.

The actions/installer/src/bootstrap.ts file defines updated SHA256 values and includes values for Windows, macOS, and Linux, along with their amd64 and arm64 variants.

The only caveat to this support is that the SLSA Verifier only started releasing builds for Windows and macOS as of v2.1.0, so attempting to use this Action with an older version would result in an error (which is tested and called out in the README).

Versioning

There is now a version input to allow the user to install specific version of the SLSA verifier. By default this with use the GITHUB_ACTION_REF environment variable like the previous verison of this Action would. There is a test included to ensure this sort of logic will work.

Inputs that are allow are:

Caching

I saw that the @action/tool-cache package was being used but it was missing a crutial step to actually utilize the Runners cache. I've updated the logic to actually cache files, so existing binaries on the runners will be used to speed up the process. Cached binaries will always be validated.

I also added logic to skip re-installing the SLSA Verifier if the version is the same as the bootstrap version. Since we already validate that directly with it's SHA256 we can simply re-use it.

The bootstrap binary is cached the same as the main binary.

You can use the cache input to manually override the caching behavior. If you use false it will still use the Runner tool-cache location, but will always overwrite the cache. This is true for the bootstrapper too.

Installation PATH

Because we're properly using the Runner tool-cache the final binary no longer needs to be in the users HOME directory. Instead the PATH will be updated with the Runners cache location, like mentioned above.

This should have no impact on anyone unless they were strictly relying on having the bin in their HOME vs in their PATH.

Testing, Linting, Formating

The standard eslint Linter and prettier Formatter (that are used with most modern TypeScript Actions) have been included to keep things aligned automatically. Most of the code aligned to this already since I don't think too much changed in that regards, but the tooling has been updated and validated.

This is included as part of the npm run all command and the Workflows, but can be triggered individually with npm run format:write and npm run lint

Test coverage has been completely overhauled to include more test cases and coverage and much more thorough integration testing with the Action itself. There are 30+ TypeScript tests (~5s), including 30+ Integration tests (60s) with a workflow where it is not easy to mock locally.

This is incorporated into the npm run all command and the Workflows, but can be triggered individually with npm run test.

The Makefile was updated to include the equivalent commands.

Workflows

Both the e2e.schedule.installer.yml and update-actions-dist-post-commit.yml have been completely updated to support this new setup. They will "just work". The E2E Workflow is where the Integration tests take place, which include a number of matrixed operations to fully validate the Actions various cases across every supported platform.

The E2E Installer Action CI will trigger on any changes to the Workflow file itself or on any file changes in the actions/installer/ directory, on the main branch.

The update-actions-dist-post-commit.yml Workflow no longer generates a .patch file. Instead, it will move the entire dist/ folder and git add them in the job with higher access.

The previous Worklfows appeared to have been failing, so I needed to fix them in order to properly test things anyways.

Misc

Other files in the root of the actions/installer that were changes were related to linters, testing, etc. They are just part of a TypeScript Action.

The source files are updated with the SLSA Apache-2.0 LICENSE notice at the top of each source .ts file.

jasmine testing suite replaced with jest and lib is replaced with the newer dist naming convention

IAreKyleW00t commented 2 months ago

Now noticing that the pre-submit.actions.yml may be a better place for some of the workflow jobs. Let me know if any of those should be moved around.

ramonpetgrave64 commented 1 month ago

Thanks for submitting the PR. To make reviewing easier, please revert the formatting changes across the files. Also let's deal with one problem at a time: Let's have one PR about only fixing the node16 deprecation, and then we can followup about multi-os, caching, and other issues.