Deploy production frontend on release & correctly time staging deployment

[sarayourfriend]

Fixes

Fixes #1557 by @sarayourfriend

Description

Deploys https://search-production.openverse.engineering whenever a release is cut in this repository. At least hopefully! We'll need to see if the GHCR configuration actually works for releases and if it will successfully trigger the "deploy-production" workflow to completion with the release tag. Unfortunately I'm not aware of any way to test this functionality other than by merging it and see if it works with a test release.

I also noticed that the staging deployment and the GHCR push to the main tag have a race condition. I've fixed that in this PR by only running the staging deployment after the GHCR image is uploaded after a push to the main branch.

Also: I've removed the old push_prod and push_staging workflows that were used to push images to ECR. We no longer use ECR, so those workflows will fail until they're removed.

Also: this adds the version.json requested by the Nginx sidecar issue. I think we can safely close that issue for now and in the future look into whether we want to use Nginx to serve static files. We don't currently do that, and the version.json endpoint isn't worth the extra complexity for now.

Testing Instructions

I think just merge and see how it goes. Note that the existing GHCR push should still work for this branch. You can see I did a bunch of test commits to get the action changes verified as working, in particular the tag extraction for the RELEASE build arg.

To test the build arg, checkout this branch and run:

docker build . --build-arg RELEASE=super-sweet-release-sha-1234abcd -t openverse-frontend:latest

Run the generated image and verify that you can reach the /version.json endpoint at http://localhost:8443/version.json:

docker run -p 8443:8443/tcp openverse-frontend:latest

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• [N/A] I added or updated tests for the changes I made (if applicable).
• [N/A] I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[github-actions]

Storybook and Tailwind configuration previews: Ready

Storybook: https://wordpress.github.io/openverse-frontend/1556
Tailwind: https://wordpress.github.io/openverse-frontend/1556/tailwind

Please note that GitHub pages takes a little time to deploy newly pushed code, if the links above don't work or you see old versions, wait 5 minutes and try again.

You can check the GitHub pages deployment action list to see the current status of the deployments.

[zackkrida]

Let's try it! Regarding rollbacks, how were we going to handle those? Was it manual runs of the GitHub workflow with a tag input field?

[sarayourfriend]

Let's try it! Regarding rollbacks, how were we going to handle those? Was it manual runs of the GitHub workflow with a tag input field?

Right! I forgot about that. I'll create a new "rollback production" workflow that can be dispatched with a ref input. It'll just call through to the production-frontend-deploy action with the input ref.

[krysal]

This is exciting and fun automation! 🚀 I left some questions but nothing blocking.

[krysal]

Will this deploy to staging on each push in a pull request (to main)?

[sarayourfriend]

No because the push event is scoped to the main branch.

You can confirm this is true by seeing that this workflow step was skipped in this PR: https://github.com/WordPress/openverse-frontend/runs/7283335174?check_suite_focus=true

[krysal]

I see, makes sense! Though then is the on: -> pull_request: ... scope doing something in this workflow? 🤔
I remember we used to publish an image for each PR but seems that has been lost at some point.

[sarayourfriend]

We do still publish the image for each step. You can see that happening on this PR 🙂 The pull_request trigger does just that.

We just skip deploying for anything that isn't a push to main (for staging) or a release.

[zackkrida]

I wanted to test the version route locally after building the dockerfile with something like docker build . -t openverse-frontend:latest --build-arg RELEASE=whatever but the Dockerfile doesn't build on an M1 mac.

[sarayourfriend]

I wanted to test the version route locally after building the dockerfile with something like docker build . -t openverse-frontend:latest --build-arg RELEASE=whatever but the Dockerfile doesn't build on an M1 mac.

Ah, this is a known issue that we decided to accept. It has to do with some permissions issue with the COPY commands, IIRC.

I've pushed an update to change the chmod to chown. @zackkrida can you try again?

[sarayourfriend]

I'm going to merge this as it's working in CI and for me locally, the worst case scenario is that it still doesn't build on an M1, but I think it should fix it. If not we can open another issue if we still wish to address this.