#office-hours (2024-02)

Hi everyone

We came across policy-bot and eagerly deployed it without realizing we couldn’t do what we had hoped to do.

We run a large Open Source GitHub organization with hundreds of repositories. We are a small business. Adding trusted contributors to our enterprise organization as outside collaborators or team members is cost-prohibitive (this is what we currently do).

We would like to instead follow in the footsteps of kubernetes/test-infra to implement a ChatOps style mechanism to approve PRs for testing and separately approve PRs for merging. Under the hood, this project uses prow.

We would like this solution to play well with GitHub Action triggers

Ideal Workflow

1. Untrusted open-source PR is opened against one of our repos from a fork (never a branch in the repo)
2. A vetted contributor inspects the PR. If it looks good, they comment /ok-to-test
3. policy-bot receives the payload, and applies its advanced policy controls. Instead of approving the PR, it can be configured to comment on the PR with something like /terratest (or add a label, such as ok-to-test)
4. GitHub Actions configured on the PR trigger on comments from the policy-bot or labels. Note, non-org members cannot add labels.
5. Tests pass
6. policy-bot awakens and approves the PR (as a CODEOWNER), so branch-protection rules now pass
7. A vetted contributor now decides if this PR is mergeable, and then comments /ok-to-merge
8. Something like bulldozer then auto-merges the PR.

Limitations

• The major limitation seems that policy-bot cannot interact with PRs beyond approving them, and we cannot approve a PR without first running tests. • We cannot run tests automatically on untrusted Pull Requests from open-source forks due to the massive attack surface and the requirement that tests have access to secrets required to validate terraform code.

Alternatives considered

1. Implement a native GHA solution. GHA suck for ChatOps. It’s like talking to the Mars Lander. Commands take minutes to receive an acknowledgment.
2. Trigger GHA on policy-bot status checks. GHAs can only trigger on status checks in the default branch, precluding it’s use on PRs
3. Write a custom bot using one of the plethora of GH bot frameworks. We would like not to have to maintain a custom solution.
4. Deploy prow used by test-infra, however, the project feels overwhelming in complexity and doesn’t seem to support GHA (only Jenkins), a requirement for us.

Container image creation tool

Two questions:

1. External Secrets Operator alternatives? Where our kubernetes applications (high # transactions per min) need to write and read secrets from an external secrets management system. we looked at dapr, eso, and some others, but they only support reading secrets from the source.
2. Anyone ever deploy things to kubernetes hosted on vmware infra?

Firefly provides the cloud infrastructure management tools missing from traditional CMDBs

Nitric Open Source Cloud-Native Framework auto-provisions infrastructure for your app from any language for any cloud. Launch now with AWS, GCP and Azure.

Use the Free Tier API to programmatically get your free tier usage.

Unlock superior Git workflows with Gitness. Experience seamless code reviews, robust CI/CD solutions, and up to 4x faster pipeline execution. Begin your journey in just 30 seconds.

We have some great news! Octopus Deploy has acquired Codefresh in a strategic investment to combine forces in creating the best CD and CI platform. Octopus Deploy is a leader in continuous delivery, especially for VMs and Windows with recent additions for Kubernetes while Codefresh has been wholly focused on cloud-native applications. Together, our goal […]