Lullabot
Add config option for MANUAL ONLY pantheon review apps / multidev deploy github action
Situation:
site with very limited github minutes, with automatic updater, does not have enough minutes to deploy every PR automatically.
example site 1: PantheonReviewApps.yml is $18 a month example site 2: 11 repos all sharing 3000 minutes, estimate adding PantheonReviewApps.yml adds 3732 additional minutes, 2115 minutes over 3000 free, adding cost $170 / month. [If we used 3000 of the free for other things, 3732 PantheonReviewApps.yml would add $298 / month.]
Want:
Only deploy branches to multidevs when QA needs them.
Workaround:
Use the pantheon multidev branch deploy from the pantheon dashboard. Cons: pantheon deploy would not follow https://architecture.lullabot.com/adr/20230929-drupal-build-steps/
Request:
- Add config option for MANUAL ONLY pantheon review apps / multidev deploy github action.
- Document choice of setup in ReadMe.
We discussed this and @YesCT is going to do some more research on how much of an impact this is having
I don't know how this could be configured at the drainpipe level but
Cons: pantheon deploy would not follow architecture.lullabot.com/adr/20230929-drupal-build-steps
if it can, maybe do this based on a PR label, then you can have best of both worlds.
Thinking about this more, one thing we did on a previous project was allow labels to control if a multidev was built or not. So if a PR had the "skip-pantheon-multidev" label, it would not run the job. We also didn't build draft PRs until they were ready for review, but then also made it possible to add a "draft-pantheon-multidev" label for those draft PRs to opt-in to a build if someone wanted one. Would it be possible that a repository could be configured to automatically add a label for every PR so that we could use a label-based approach?
I like the idea of a label. Rather than skipping though, I think it should be opt-in - if the label is there, we build the multidev. Something like build-pantheon-multidev?
I think it should be up to the project frankly, we found it really useful to have PRs automatically build environments, especially with our once-a-week auto-updater because we also tied the deployed multidev environments into automated tests and accessibility reviews. I just feel that opt-in isn't a smooth transition from the current behavior. It gets a little weird with the logic of draft or not, tag or not, one tag for opt-in or opt-out might be best.