cockroachdb / cockroachdb/helm-charts
CI Process moving forward
- Dominant language
- Go
- Stars
- 105
- Forks
- 152
- Avg merge
- 4d 23h
- Merged PRs (30d)
- 5
Description
From prafull01
**Current approach:** It is to build the cert signing utility, push it to the GCR repo and use that image in our tests. To implement this approach, we had to use the pull_request_target which allow forked workflows to have access to the GCR tokens.
_Advatages_:
You have to build the image only once and use it in as many tests you want.
_Disadvantages_:
The forked workflow (untrusted) will have access to the GCR token and will be able to push the image to our GCR repo.
The multiple pushs on a PR, may be because of bug fixes, review comments etc, builds a new image will be pushed to GCR. Again waste of resources for us.
Every CI change we need have to merged before it can actually run, because pull_request_target checkout the code of the master and then we apply the pull request head ref on top of it.
**Alternative Approach**: Instead of building and pushing the image, we only build the image as one step in the every e2e tests job and do not push it to GCR repo. Hence workflow don't need the access to GCR repo . This build image on the same github runner can be used to run in tests. We will add a post job which triggers on merging a PR and it will initiate a docker build and push that to the GCR repo. So we will have only single image per PR merge in our GCR repo.
_Advantages_:
The forked workflow don't need access to GCR token through secrets.
Only merged PRs 1 image will be pushed to GCR repo.
CI can be tested while making the change as pull_request runs directly on the pull request and if the pull request have the CI change it incorporates those changes.
_Disadvantages_:
Might have to build the docker image multiple times, here 2 times. One for E2e for install and E2E for rotate..
/cc @rail @keith-mcclellan lets discuss here
Jira issue: HELM-5
Contributor guide
No contributing guide indexed for this repository
Research direction
No files or tests are named. Start by reviewing the current pull_request_target workflow, the E2E test jobs, and the proposed post-merge job; done should mean pull requests build locally without GCR credentials and only merged changes push one image to GCR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, github-actions, google-cloud
- Domain
- ci-cd, cloud, devops
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100