Easton Crupper

> i don't know if it's just me, but it seems counter intuitive to have `status: failure` that will _run_ the step on build failure and then `stage_status: failure` which...

I am going to close this PR in favor of pursuing a purely worker repo solution: An independent stage should only use the `status` rule for its own stage's status....

Putting in draft right now. Functionally it's there, but I'd like to work out more comments, address some tests, and search for more optimizations

This extends to comment steps with additional `comment` specification, e.g. ```yaml - name: comment-with-bug image: golang ruleset: event: comment comment: "test suite" commands: - echo "running comment-driven test suite" -...

@dependabot rebase

To add some additional context, I think the fact that this is a recent development points to [this change](https://github.com/go-vela/server/pull/1038) as a potential culprit. Previously, `delete` pushes were promptly discarded and...

> Conceptually, the sidecar container makes me think of a supply chain attack via that container. Will there need to be any validation step-by-step to ensure the output of one...

> not a fan of this solution, we're now potentially doing a whole lot of work for a hook that won't produce a build, aren't we? we do the same...

> > we do the same for events not allowed, builds that get skipped due to no matching rulesets, and repos that are no longer active — all of which...