Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce action runtime #74

Closed
Tracked by #75
joshuagl opened this issue May 20, 2022 · 7 comments
Closed
Tracked by #75

Reduce action runtime #74

joshuagl opened this issue May 20, 2022 · 7 comments
Labels
area:go Issue related to the Go ecosystem

Comments

@joshuagl
Copy link
Member

I have projects which take about ~30s to build where adding the provenance only workflow to those projects significantly increases build time because building slsa-github-generator takes >2min.

It would be good to reduce build time, or otherwise decrease the runtime of the action, before encouraging wider adoption.

@joshuagl joshuagl mentioned this issue May 20, 2022
@laurentsimon
Copy link
Collaborator

laurentsimon commented May 20, 2022

Thanks for raising this problem. A quick look at the e2e integration tests (https://github.com/slsa-framework/example-package/actions/runs/2357668677) show that building the builder takes 2mn, while other VMs finish in a few seconds. Numbers from the link above:

  • 26s to download dependencies
  • 1.42mn to compile

I added some logging and re-ran the re-usable workflow:

  • Dependency download: ~30s
  • Builder's build: ~1.30mn
  • Builder's binary upload: ~5s
  1. Use a container image + provenance for it (do-able using the ko trusted builder, but requires ko to be ready)
  2. Use a container image + sign the image using cosign (as a step towards previous option)
  3. Use a Dockerfile for the action, and pull the builder binary from the GH release assets and verify its provenance before using it.
  4. Pull the binary + provenance from the GH release and use it
  5. Dont do any of the above if the build is reproducible (?) Unlikely and harder for someone to verify

There's a bit of a chicken-and-egg problem to solve for each option. But there's probably a way to solve that. Also note that verifying provenance requires the slsa-verifier, which will take the same amount of time to build, so we'll also need to pull the binary from a release

Thoughts?

@laurentsimon laurentsimon added this to the v1 milestone May 20, 2022
@laurentsimon
Copy link
Collaborator

laurentsimon commented May 24, 2022

I'm working on this. TL;DR:

  1. I'll introduce a new workflow option compile-builder which will optionally build the builder from source. By default it will be false. We need not advertise this option.
  2. For releases of this repo and the slsa-verifier repo, we'll always build from source
  3. When users build, they will mostly use the pre-built builder. So the re-usable workflow code will roughly do:
    3.1 Resolve the @hash to a version/tag (for v1 we're not going to support hash but the code will be there anyway)
    3.2 Given a version (@v1.2.3 or resolved from previous point), we will download the builder's binary and provenance
    3.3. We will download slsa-verifier from release and verify its hash with a hardcoded value
    3.4. We will use the slsa-verifier's binary to verify the provenance of the builder (commit hash, tag, source)
  4. We will run the builder

Note: for the verifier, we need a hash since the verifier cannot verify itself, i.e. it's untrusted upon download. So we will keep a list of good hashes in the verifier's repo. After a release, I will create a PR with a mapping between a release binary and a release tag. Other maintainers will verify the hash of this binary is correct by:

  1. Verify that the workflow used to generate the release has the option compile-builder set to true
  2. Locally download the untrusted verifier binary from the release assets
  3. sha256sum this untrusted binary
  4. Clone the verifier source code locally (trusted, since it has code reviews turned on)
  5. Build the verifier as trusted-verifier
  6. Run the trusted-verifier on the verifier binary downloaded in step 1
  7. LGTM the PR

We can build a little utility later to simplify this.

@laurentsimon
Copy link
Collaborator

See #86 and slsa-framework/slsa-verifier#63

Once they are merged:

  1. I'll cut a v0.0.1 release for the builder
  2. I'll cut a v0.0.1 for the verifier, using the v0.0.1's builder release
  3. We-ll update the verifier hash as described in previous comment
  4. We'll update the hash https://github.com/laurentsimon/slsa-github-generator/blob/feat/fastbuilds/.github/workflows/builder_go_slsa3.yml#L30

From there we can update the hash/tag of the verifier when we need to.

This was referenced May 25, 2022
@laurentsimon laurentsimon added the area:go Issue related to the Go ecosystem label May 25, 2022
@laurentsimon
Copy link
Collaborator

laurentsimon commented May 25, 2022

going to cut a v0.0.1 release to test the entire flow. The verifier will only accept reusable workflows pinned by tag (not by @main). The builder supports pinning by hash, but not the verifier yet. We can do that later - see discussion in slsa-framework/slsa-verifier#12

@laurentsimon
Copy link
Collaborator

@joshuagl can you check the new builder @v0.0.2 and tell me if the build is faster? The builder's binary is pulled from the release assets; it takes ~20s instead of ~2mn. However the overall build will still take longer depending on VM scheduling.

@ianlewis
Copy link
Member

I think we can close this for the Go builder?

@laurentsimon
Copy link
Collaborator

This is done. Closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:go Issue related to the Go ecosystem
Projects
None yet
Development

No branches or pull requests

3 participants