Add a CI workflow to confirm that Starshot can be spun up with DDEV.

[phenaproxima]

Following up #50. We should really confirm continuously that Starshot works with DDEV.

[TravisCarden]

@phenaproxima, by way of review... This is my read of your intentions. Is it accurate?

The job runs...

• on...
  • pushes to main or wip
  • pull requests to main
• or every 12 hours on the main branch only
• or when triggered manually
• but only after the "Main" workflow run is complete

I have a concern that the behavior when combining workflow_run with schedule or workflow_dispatch is unspecified and may lead to unexpected or variable results. It would be much safer (and simpler) to make this a separate step in the "Main" workflow instead of a whole separate workflow. Since you're running it on all the same triggers as "Main", the effect would be essentially the same. The only argument against it would be if you need to be able to run just the "DDEV" workflow without the "Main" workflow--though even that could be effectively done by canceling individual jobs on the presumably rare occasion you would want to do it. So that's what I recommend. What do you think?

[phenaproxima]

@TravisCarden I feel like it should be a separate workflow, but how about this: what if we simply trigger it:

• only on main, and PRs to main
• only when the Main workflow has succeeded

...and forget the scheduling, and manual dispatches?

[TravisCarden]

That seems wiser to me, @phenaproxima. 👍

[TravisCarden]

Okay, @phenaproxima. It appears that GitHub Actions will only run a dependent workflow (i.e., one that's triggered by another one) when it's on the main branch. And it seems like it always runs the version of the dependent one that's on the main branch--at least that's what my testing suggests so far. I don't know what that will mean for pull requests that change the new workflow. But I'm going to go ahead and merge this just to get it in the main branch where I can confirm that it's working. We can create follow-ups as needed.