-
Notifications
You must be signed in to change notification settings - Fork 63
Staging and production deployment workflows #563
Conversation
I am not sure I can really comment on this PR due to my lack of knowledge in this area, but I love the automation! We have only one staging env, right? It could probably be nice if it was possible to also stage the feature branches (audio integration, redesign) before merging them into main. |
I like how you've separated the work here, it makes sense to me. I think if we ever needed more environments we'd just refactor how this works completely and perhaps not even use GitHub actions. |
Feel free to undraft this so you can test it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few thoughts/questions!
.github/workflows/build.yml
Outdated
|
||
# for production | ||
# gather metadata from git & github actions to reference in docker | ||
- name: git & github metadata production |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of similarities between this and the staging step. I wonder if we might be able to combine the logic and add conditions in certain places for each deployment case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point, and that's what I mentioned when I officially announced this PR.
This is something that will be improved in the future based on what we are going to see when deploying this on the real infrastructure.
By now, I'm separating the logic between staging and production, but I'm planning to send a PR to the official action project (owned by Docker) that allows me to manipulate the tags without the need to duplicate the whole step.
cc @zackkrida
.github/workflows/build.yml
Outdated
context: . | ||
tags: ${{ steps.metadata_production.outputs.tags }} | ||
labels: ${{ steps.metadata_production.outputs.labels }} | ||
push: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this push trigger a deployment of our AWS infrastructure? Is that encapsulated in this workflow or will that be future work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deployment is made by CodePipeline in our AWS. I just push the image to ECR and the event will automatically be triggered internally.
That's why I opened a discussion a few days ago, because I would need to change this part and build some communication between CodePipeline and ghcr.io events.
* main: (73 commits) Make audio/image pages without ids show a 404 (#768) Fix logo button paddings and simplify implementation (#767) Fix global audio rtl close placement (#780) Check for `null` localStorage explicitly (#763) Truncate global audio text to two lines (#773) New image details page (#682) Switch to path-based i18n routing (#701) Enable source maps in production (#755) Remove Jamendo and Wikimedia Commons from audio meta sources (#747) Use jed1x json format to correctly handle pluralization (#753) Fix logo color on error page layout (#752) Add homepage content switcher for mobile screens (#716) Add inline-start border to filters on desktop (#748) Fix header items not fitting in (#718) Expose `close` to popover content via slot props (#736) Truncate row layout audio titles (#735) Stop blocking on analytics requests (#715) Style links globally (#727) Refactor the usage of i18n result count computation (#707) Use `VPopover` for the content report form (#719) ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing an issue, it appears the run failed with an error: https://github.com/WordPress/openverse-frontend/actions/runs/1785344194
Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/openverse-frontend/openverse-frontend/.github/workflows/build.yaml@v1'. Did you forget to run actions/checkout before running your local action?
… production environment
The pipeline has been fixed and you can consider it ready for review. |
The build workflow was moved as an - name: docker build
uses: ./.github/actions/build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I left a few suggestions!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Description
This Pull Requests separates the workflow that deploys to staging should take comparing with production.
In the case of STAGING we want the deployment to be executed when a pull request is merged to the main branch, or when there is a direct commit to that branch.
The tags that must be applied for that environment are those related to the last commit (short sha) and also the tag:
latest
.For PRODUCTION, the tag
latest
shouldn't be applied, instead of that, the wordstable
is the one to be applied.Testing Instructions
main
branch (deploy to STAGING)Checklist
Update index.md
).main
) or a parent feature branch.Developer Certificate of Origin
Developer Certificate of Origin