Dave Reid

My proposal (with approval already from @justafish) is to replace updating the PR body with a sticky comment using https://github.com/marocchino/sticky-pull-request-comment.

Also would be looking to remove DDEV as a dependency of this task to help speed up the job (would also fix https://github.com/Lullabot/drainpipe/issues/239) and just use composer natively like we...

I think it would still need to run on push because it's possible for a PR to have a composer.lock change initially, but then *not* have one after merging in...

I'm not sure that bundling it is a wise idea, if static tests fail, or DDEV fails to spin up, we run into the same problem where PRs won't have...

Yeah, I think there's a benefit to smaller update PRs if you have all the automated, regression, and visual diff testing able to auto-approve things. There's also issues with multidev...

Yes, +1 to this, using a phpstan.neon.dist is preferred and what we provided via scaffolding on a shared install profile across several sites, which allows individual projects to still use...

+1 for including _necessary_ command binaries via Dockerfile, I've found it the most reliable way and they're ready to use as soon as DDEV starts without composer. On another project...

+1 to this as well. Some questions on this based on me doing this on another project in the past: Would we be okay sites using the environment protection with...

Is this because the PR is coming from a fork? I'm guessing so since GITHUB_TOKEN doesn't have access to creating deployments on the parent repository.

Yup, we used a fallback to the previous environment name so it worked automatically for existing installs.