#release-engineering (2022-03)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2022-03-01
My team ~hates~ dislikes the /test all chatops that I set up in order to run GitHub Actions that require secrets from forks. (I copy/pasted CloudPosse’s slash-command-dispatch.yaml) We looked at enabling that setting that requires approvals before pipeline runs from forks, but it only requires an approval once from a given user. It’s a mitigation to prevent annoyance and frivolous pipeline runs, not to protect the repo’s secrets.
Is there any other option? I’m sure you guys have looked at this a lot.
For the record, I hate the /test chat ops as well, the only reason we do it is there is no other way to run the tests for PRs from forks in a safe way
this is why organizations like Kubernetes use chat ops
So it would be helpful to understand what part that needs solving
It’s a mitigation to prevent annoyance and frivolous pipeline runs, not to protect the repo’s secrets.
in this case, require a label to be added to the PR for tests to run
then just have them trigger in standard PR synchronizations
I’ll go look for an example of Kubernetes using chat ops, that would be helpful. Thanks
Context ^
can you further define “annoyance and frivolous pipeline runs”?
and, are you able to use filters, instead? split the workflows up, and use filters to declare when they should run…
on:
# Run on demand
workflow_dispatch:
# Run pull requests against the main branch
pull_request:
branches: [main]
paths:
- 'Dockerfile.*'
- '.github/workflows/build.yml'
- 'package-templates/**'
# Run when a release is created
release:
types: [released]
This is the setting I’m referring to. From the doc that it links:
Although workflows from forks do not have access to sensitive data such as secrets, they can be an annoyance for maintainers if they are modified for abusive purposes.
right, but you said it was not about secrets
Right, this setting isn’t about secrets. My needs are about secrets. How can we safely run github actions from forks that need secrets to run, without needing to do the chatops command? My understanding right now is, “you can’t”, but I’m looking for as much information as possible
From people smart on the topic
ahh, it wasn’t clear that the jobs were using secrets, just that chatops was creating kinda “on-demand” runs
i’m not familiar with how slash-command-dispatch works… but even with a pr from a fork, jobs are still triggered even if they use secrets. it’s just the secret is empty. so, presumably, you could have a job that acts like a webhook and kicks off something else that does have access to the secrets?
hah!
We settled on a hybrid approach, doing as many workflows as we can that don’t require secrets, and still using chatops like we have been for the ones that do need secrets
Thanks for the input everyone! It was super helpful