Refactor smoke tests to use submodules

[natemoo-re]

Changes

• Follow-up to Make smoke tests more deterministic #2618 which added our smoke tests inline to the repo. This caused a lot of trouble with rebasing because all commits and changes are tracked for these directories, even though they have their own commit flow.
• Uses git submodules to manage the astro.build and docs smoke tests. These will only be fetched for the smoke test action and will always fetch the latest commit to main. It's automatic and doesn't require an action to sync these nightly.
• Contributors shouldn't have trouble with this because git pull won't fetch submodules by default.

Testing

CI

Docs

N/A

[changeset-bot]

⚠️ No Changeset found

Latest commit: 57a4e6a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[natemoo-re]

This is the extent of the changes to our actions. This pulls in the submodules recursively, so they always reflect the latest commit to main every time they run.

[natemoo-re]

This points ./smoke/docs to [email protected]:withastro/docs.git and smoke/astro.build to [email protected]:withastro/astro.build.git. They both should reflect the main branch.

By default, git pull doesn't populate these directories unless you explicitly opt-in to that behavior (which most users won't need to do)

[natemoo-re]

I should mention that users won't do this often, but our smoke test action can specifically populate them just for that run. Seems much better than the previous system!

[matthewp]

Needs to be rebased :(

[FredKSchott]

@natemoo-re from my comment here: #2618 (comment)

I'd still love to try our current system for another week, but if it's already been a pain for maintainers in so little time then I'm +1 on this PR. I'm just surprised that this has impacted rebasing since we should never be touching that directory... but I guess they still find their way into the rebase diff?

Regardless, +1 if you feel strongly.

One thing to watch out for, that I realized in the smoke sync script: checking out these git submodules locally and then re-running yarn will produce a different yarn.lock than you'd expect. If we can assume that only advanced maintainers are running smoke tests locally, then I guess we could just document this somewhere or remember to keep an eye out for it when reviewing PRs.

[natemoo-re]

Thanks @FredKSchott! Yeah unfortunately the automatic sync PR merge commits still get picked up when you rebase from main, so you have to sort through all of those changes on top of whatever you're actually changing.

I'll give the yarn.lock issue a once-over before merging this.