Build in devcontainers in CI - #371
Conversation
mattgara
left a comment
mattgara
left a comment
There was a problem hiding this comment.
One issue related to credentials exposure, but otherwise LGTM.
| imageTag: cuda${{ matrix.cuda }}-${{ matrix.arch }} | ||
| cacheFrom: ghcr.io/rapidsai/velox-testing/devcontainer:latest-cuda${{ matrix.cuda }} | ||
| env: | | ||
| AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }} |
There was a problem hiding this comment.
This looks to pass a 12-hour AWS session plus an sccache auth token into code from the PR checkout. I'm not sure in what context the dev containers are supposed to be used, but could we consider moving this credentialed build behind a manually dispatched workflow on main and a protected trusted-pr-build environment, with a manually maintained trusted team as required reviewers? This is mostly to prevent someone accessing said credentials in their PR's container unbeknownst to us.
There was a problem hiding this comment.
@trxcllnt Can you comment on this? I think I followed what we're doing everywhere in our CI workflows. Is this a concern?
There was a problem hiding this comment.
Yeah what @bdice has done here is fine. We do this everywhere, and the guidance is the same as the requirement for using NVIDIA's GitHub Actions runners: don't run PRs from third-party sources without reviewing them first.
3 participants
This enables devcontainer builds in CI for verification of builds.