Run nitro-deploys CI on nitro PR

[Hebilicious]

Describe the feature

When we make a PR in nitro for a new preset, there's no straightforward way to trigger nitro-deploy CI with the proposed changes.

• We could build a bot that allow us to use a /trigger deploy [preset-name] command in the nitro PR.
• We could move this repo to nitro and use workflow file filtering to avoid over-deploying.

Additional information

• Would you be willing to help implement this feature?

[Hebilicious]

cc @pi0

[pi0]

Some (many) of our presets are set up with the ability to have one deployment and do not support preview branch deployments. Best we can do is to automate the nitropack-edge version bump from main nitro CI once a commit is merged to main to trigger nitro-deploys

[Hebilicious]

@pi0 For the github integrated presets we can create a staging version if we don't have a preview branch support.

Example with CFP (Note that CFP supports preview branch so it wouldn't be necessary)

1. configure CFP staging to be deployed on commit to a cloudflare-pages-staging branch.
2. use /trigger cloudflare-pages in a nitro PR (this push a commit to nitro-deploy@cloudflare-pages-staging with a version of nitro that includes the PR change)
3. Provider github integration deploys the app on staging.
4. bot returns the url of the app in the PR

This mean that the staging environments must be previewed sequentially as they are overwritten by new /trigger

This is better than not testing or manual testing.

(All of this is simpler if this is handled in the same repo.)
(If we have preview branch support this is even cleaner as each commit has a deployment)

[pi0]

Thanks for explaining. I'm aware of this possibility but presets need to have unit tests to be passed before merging them on a nitro PR.

This repository is meant to be an end-to-end testing suit not only testing the latest nitro preset builds but also the platforms themselves to be compatible and working (a breaking change can happen in the platform, not by nitro changes!).

A preview branch would be nice but again, not every preset is capable of supporting such a configuration. Right now even one branch deployment of many of them is partially working and breaking from time to time.

Adding more complexity or combining such complexity to the main repo is not sensible.