Deploy to staging automatically on release

[AetherUnbound]

Description

This is a small change to the CI/CD workflow to automatically initiate a deployment to staging when a release is cut.

Testing Instructions

N/A

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.
• I added or updated tests for the changes I made (if applicable).
• 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]

Full-stack documentation: Ready

https://WordPress.github.io/openverse/_preview/883

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.

[dhruvkb]

Will we be cutting releases in the future? I'm not opposed to the idea but I thought that was no longer possible due to the out-of-sync release cadence of the projects inside the monorepo.

[AetherUnbound]

Will we be cutting releases in the future? I'm not opposed to the idea but I thought that was no longer possible due to the out-of-sync release cadence of the projects inside the monorepo.

We will! We'll just be able to selectively deploy a release against either the prod frontend or API (or both) at our own discretion 🙂

[zackkrida]

I'm not necessarily opposed to this, but I'm not understanding what it is for. No rush but could you explain the motivation somewhere @AetherUnbound?

[AetherUnbound]

I'm not necessarily opposed to this, but I'm not understanding what it is for. No rush but could you explain the motivation somewhere @AetherUnbound?

I believe the previous behavior for the frontend was that, when a release was cut, the frontend would automatically be deployed at that tag. This PR maintains that behavior and also applies it to the API as well. The alternative would be for us to manually deploy a release tag to staging come on which seems unnecessarily manual IMO.

[dhruvkb]

@AetherUnbound the main issue with releases is that it will tag the entire codebase at a particular commit (every layer of the stack).

Apologies if I'm misunderstanding, but it seems that with this change, we will be deploying every layer on every release, in sync, with the same version number, even if nothing has changed or something is incomplete?

[AetherUnbound]

Apologies if I'm misunderstanding, but it seems that with this change, we will be deploying every layer on every release, in sync, with the same version number, even if nothing has changed or something is incomplete?

I think a point of clarification would be that we will be deploying every layer to staging on every release, in sync, with the same version number, even if nothing has changed. Even if something is incomplete, we already deploy both the frontend and API to staging on every push to main (depending on if the service code is affected) so whatever code is out there already would merely be re-deployed. This simply prevents us from having to initiate both the staging and production deployments manually during the release process.

[dhruvkb]

Just noting that some of this is ideologically conflicting with #895 which tries to skip as many steps as possible (including image building and publishing) if files haven't changed.

[AetherUnbound]

Ahh, that's an interesting point. I think it makes sense to build & push images for all services when a release is made, though now that you mention the job skipping I'm not even sure that'd happen with our workflows the way they're currently set up 😅 I guess it depends on how get-changes computes changes for a given release; i.e. does it compute the changes made since the last release? Since this still requires that the images be pushed for a tag in order to actually run the deployment for that tag on a service, I don't think it's necessarily in conflict (although that would mean that deployments would only happen to staging on a release if there were changes since the last release, again assuming that's how get-changes is computed for releases).

[AetherUnbound]

We discussed this publicly here and will be going with an alternative approach: https://wordpress.slack.com/archives/C02012JB00N/p1678808559132249