Docs: Add subsection for running Prow outside GKE (e.g., local/Kind)

[tsj-30]

While setting up Prow for local exploration and development, we noticed that the current Deploying Prow
guide is primarily written with Google Kubernetes Engine (GKE) in mind. Although the document states that “Prow runs in any Kubernetes cluster,” most configuration examples and environment assumptions are Google-specific.

Problem

• This GKE-centric approach can make it challenging for new contributors or developers who want to:
• Experiment with Prow locally (for learning, testing, or extending plugins/UI).
• Run Prow on lightweight environments such as Kind.
• Validate PRs, configs, or plugin changes without relying on cloud infrastructure.

Currently, there is no dedicated subsection that explains how to set up Prow in non-GKE environments. This limits readability and creates a barrier for those exploring Prow in alternative setups.

Proposed Improvement

• Add a subsection (for example, under “Deploying Prow”) that describes:
• Minimal local setup instructions using Kind:
• Create the cluster.
• Apply starter manifests.
• Configure a simple GitHub App + HMAC secret.
• Call out common pitfalls during setup.
• Explicitly clarify that this setup is intended for exploration/learning, not production-like use cases.

Broaden the doc’s scope to make it less GKE-centric by acknowledging other possible environments where contributors may want to test.

Why This Matters

• Lowers the barrier for contributors who want to test PRs or changes locally.
• Makes the docs more accessible for developers working outside GKE.

[BenTheElder]

Configure a simple GitHub App + HMAC secret.

This isn't going to work well with a local cluster ... the HMAC secret is for incoming webhooks, so the cluster has to be exposed to the public internet, which we do not generally recommend with kind for security reasons (also doing so portably is a complex topic because it involves exposing your local machine to the public internet as well).

These are the parts that are generally GKE centric, because that is where Kubernetes runs prow.

For something like running a prowjob locally on kind, there are already tools / scripts / docs in the repo for that.

#283 already covers moving the starter config, which was left in test-infra when prow moved. IMHO it should be moved here and updated. PRs welcome.

Also, FYI if you're running prow outside of the Kubernetes project ... #113 at some point we will need to cut off access to pulling from staging.

[Amulyam24]

Configure a simple GitHub App + HMAC secret.

This isn't going to work well with a local cluster ... the HMAC secret is for incoming webhooks, so the cluster has to be exposed to the public internet, which we do not generally recommend with kind for security reasons (also doing so portably is a complex topic because it involves exposing your local machine to the public internet as well).

These are the parts that are generally GKE centric, because that is where Kubernetes runs prow.

For something like running a prowjob locally on kind, there are already tools / scripts / docs in the repo for that.

Hi @BenTheElder, for local job testing, there are tools like test-pj and I understand the security risk of a local setup. However, wouldn't a setup as such help when we would want to test/debug components like deck or hook? would you rather suggest the best way to go about it would be to test them separately based on requirement?

[BenTheElder]

However, wouldn't a setup as such help when we would want to test/debug components like deck or hook? would you rather suggest the best way to go about it would be to test them separately based on requirement?

for deck, we have (had?) a way to test where it would fetch data from a real prow instance and then serve a static copy of that data and otherwise run locally as a trivial go binary + static webpage contents, which doesn't really benefit from running in any cluster and already isn't GKE specific

for hook, see my comments above ... you can't trivially run that locally, it needs to receive webhooks from github ... which is inherently not fully portable (you ideally should use a public HTTPS endpoint configured against a github app which involves things like DNS outside of the cluster)

[BenTheElder]

I agree with the sentiment, but I just don't know how much is really actionable aside from #283

If you're developing the job controllers, we have that run locally already.

If you're developing hook, I think you kinda have to deal with real non-portable bits, and we have only have the resources to write that up for what we actually operate.

[BenTheElder]

Maybe a prow development guide in general is in order? cc @petr-muller