pipe-cd/pipecd

The code-butler workflow (/review and /chat comments) doesn't work anymore. I tried it on #7012 and the run failed, and none of its past runs have succeeded. It also runs on every comment in the repo, so the Actions tab is full of skipped runs. The action it uses (ca-dp/code-butler) has been archived since 2025. Since Copilot already reviews PRs, I think we can just remove it, happy to open a PR if sounds good!

What would you like to be added: Skip the heavy CI jobs (Go test/lint/build, web, integration, CodeQL) for PRs that only change documentation files (docs/**, **.md). Currently test.yaml, build.yaml, lint.yaml, gen.yaml, and codeql-analysis.yaml run on every PR with no path filters, so even a docs typo fix runs the full Go test/lint matrix (one job per module), govulncheck, web tests, and integration tests. Note: go-test-completed and go-lint-completed are required checks, so a plain paths-ignore on the triggers would leave them stuck at "Expected" and block merging. Instead, a first job can detect changed paths (e.g. dorny/paths-filter) and the heavy jobs skip conditionally the existing *-completed gate jobs still report success, so required checks keep working. Why is this needed: Docs-only changes cannot affect test/lint/build results, so running these jobs wastes CI compute and runner queue slots, and slows down feedback for docs contributors.

What would you like to be added? Some scheduled GitHub Actions workflow jobs should define timeout-minutes. These scheduled workflow jobs currently do not define one: .github/workflows/codeql-analysis.yaml: analyze .github/workflows/stale.yaml: stale I suggest adding explicit timeouts to these jobs, for example: timeout-minutes: 60 For stale.yaml, a shorter timeout such as 15 minutes may be enough because it only runs actions/stale. The repository already uses explicit job timeouts in other workflows, such as .github/workflows/build_tool.yaml and .github/workflows/publish_tool.yaml. Why is this needed? Scheduled workflows run without direct user interaction, so a stuck job can occupy a runner until the default GitHub Actions timeout is reached. Adding explicit timeouts makes these jobs fail faster when they hang and keeps runner usage bounded.

What would you like to be added: A CLI tool that generates the full scaffolding structure for a new PipeCD deployment plugin. The tool accepts flags for plugin name, stage definitions, and optional features (livestate, planpreview, rollback), then generates a ready-to-compile plugin with the correct directory layout, typed config structs, stage constants, pipeline builders, and per-stage executor stubs Why is this needed: Creating a new plugin currently requires manually replicating boilerplate across multiple files (main.go, config/, deployment/pipeline.go, deployment/plugin.go, stage files, etc) while ensuring the correct interface is satisfied and naming conventions are followed This is time consuming for developers. We need a way to reduces friction and a scaffold generator reduces The inspiration is from how kubebuilder help developers build K8s API by generating boilerplate code, let them focus on the main logic. And I believe in our case a scaffold generator lets developers focu

What would you like to be added: A helper mechanism for validating and exploring YAML configuration fields, ideally with autocomplete and schema validation support. Why is this needed: Context: When working with the ECS UpdateService API, configuration errors can be surprisingly hard to detect, especially when they involve incorrect field names that are silently ignored or not clearly validated Example deploymentConfiguration: deploymentStrategy: BLUE_GREEN # Wrong field name, it should be strategy There is no immediate feedback, the API does not clearly indicate the mismatch which led to significant debugging time. At one point, it even caused confusion for me about whether UpdateService API supports changing deployment strategy at all My implication for the above example is there should be a way to enforce and robust the way we write config. Potential solution: Leverage YAML schema validation via JSON Schema, which is already supported by tools like the Red Hat YAML Language Serv