secrets-provider-for-k8s
secrets-provider-for-k8s copied to clipboard
Release automation - Push Helm Chart to helm-charts repo
Our pipeline currently builds a helm chart as part of the build pipeline. We now want to be able to push packaged helm chart to the helm-charts repository as part of our version release
ToDo
- [ ] Challenge design and maybe create a new one after new limitations. See thread: https://conjurhq.slack.com/archives/C8BNMU0KV/p1603715930420900
- [ ] Implement and generalize the action in helm-charts to be reused by other repos/pipelines/etc
- [ ] Trigger the action from
publish.sh - [ ] Provide guidelines for how to use GH actions in Conjur
Done
- [x] Talk to infra about how to automate the pushing of our Jenkins artifacts to another repo (helm-chart)
- [x] Create POC to validate action works. See here
Help resources
- http://blog.marcnuri.com/triggering-github-actions-across-different-repositories/
- https://github.com/conjurinc/cloudfoundry-conjur-tile/blob/master/.github/workflows/draft-release.yml
Progress
POC repo: https://github.com/sigalsax/poc-github-actions
Flow
- On successful build, the Release stage will run
./bin/publish - When
[ "$GIT_DESCRIPTION" = "v${VERSION}" ], an HTTP request will be sent from Jenkins to trigger an event in helm-charts repo - The action in helm-charts repo will (DONE)
- Clone the SP4Ks Repo
- Package the helm chart
- Commit the Helm chart tgz to a helm-chart branch
- Create PR in helm-charts
HTTP request
FLOW
Notes:
- The access token will be fetched from summon beforehand
- In request ref will be ?? and the secrets-provider-ref will be an object {“secrets-provider-ref”: ?? } with info to help generalize the event.
Ex:
{
"ref": <ref>,
"project-ref" : [
{
"version": <version>,
"full_repository_name" : <full_repostiory_name>,
"helm_package_path": <helm_package_path>,
"pr_assignee": <pr_assignee>
}
]
}
version: -> 1.1.0 full_repository_name -> cyberark/secrets-provider-for-k8s helm_package_path -> secrets-provider-for-k8s/helm/secrets-provider pr_assignee -> sigalsax
The actual action will need to accept these inputs under input: in the action
Change repository_dispatch to workflow_dispatch
@izgeri suggested update design https://conjurhq.slack.com/archives/C8BNMU0KV/p1603716511421800?thread_ts=1603083343.320200&cid=C8BNMU0KV
- secrets provider add the helm chart .tgz to its github releases, like we upload ZIPs for the buildpack
- the consumer repo (eg cyberark/helm-charts), if it has a way of being alerted when a new tag is available in secrets-provider, can kick off a workflow to auto-open a PR adding the release artifact.
- the helm-charts workflow can grab the artifact from the SP gh release like how we grab the buildpack ZIP when we build the PCF tile
- the helm-charts workflow can open a PR against itself, using its own github token, like we do in the OSS suite repo when we draft a new gh release (tag-triggered) and when we open a PR to save the suite YAML
There have been some limitations that were introduced with current design.
See discussions here: https://conjurhq.slack.com/archives/C8BNMU0KV/p1603715930420900
This might require a new decision as Geri suggests where we grab the packaged helm chart artifact from releases from another workflow (helm-chart)
Geri's design: https://conjurhq.slack.com/archives/C8BNMU0KV/p1603083343320200