ci/pr-deploy: Combine build and upload jobs

[nadiamoe]

As discussed in #1182 (comment), we spend around seven minutes copying a hundred-megabyte artifact across jobs. While bigger jobs are often not ideal, in this case I think it is preferable than the artifact upload/download overhead.

With a full cache hit, this brings ci/cd time to 3 minutes. This may be due to S3 being extra smart and might be larger on the first time a PR is opened though.

[nadiamoe]

During development of this PR, I noticed it was not able to reuse the build cache from other PRs as I intended with #1182 . This is expected according to the docs:

Workflow runs cannot restore caches created for child branches or sibling branches. For example, a cache created for the child feature-b branch would not be accessible to a workflow run triggered on the parent main branch. Similarly, a cache created for the feature-a branch with the base main would not be accessible to its sibling feature-c branch with the base main

In order for PRs to be able to reuse each other's cache, we need to also cache the gatsby build in the staging job, which in turn would also speed up this job. I'll set this up on #1188, which will hopefully be the latest PR on these series :)

[nadiamoe]

Preview: https://mdr-ci.staging.k6.io/docs/refs/pull/1183/merge

[imiric]

Makes sense 👍

I did a double-take and couldn't believe the 3m36s run time 👀😀

That's a radical improvement over the previous 23m! 👏

I'm slightly concerned that the aggressive caching won't bite us in the ass in some way later (inconsistent dependencies, wrong cache shared between PRs, etc.), but I currently can't see any drawbacks to this strategy, and we can address any issues with it later.

[nadiamoe]

@imiric

I'm slightly concerned that the aggressive caching won't bite us in the ass in some way later (inconsistent dependencies, wrong cache shared between PRs, etc.), but I currently can't see any drawbacks to this strategy, and we can address any issues with it later.

I am too, at least a bit 😅

Dependencies should be alright because no cache will be restored if any of 'package.json', 'gatsby-config.js', 'gatsby-node.js' change. But we're trusting Gatsby to be smart with its cache and not leave leftover files in public/. I think this should be alright, because in a normal local develoment flow, those caches are persisted on disk essentially forever.

In any case, I purposefully left the deploy to prod job out of this caching patch series, just to be safe :)

[ppcano]

@roobre, thanks for improving the build process! 💯