-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deploy multi-platform images #1412
base: main
Are you sure you want to change the base?
Conversation
@@ -0,0 +1 @@ | |||
#!/bin/bash |
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.
TODO: write the script to actually create the multi-platform docker manifest.
Revert later
- name: Wait for Travis CI | ||
uses: fountainhead/[email protected] | ||
id: wait-for-travis | ||
with: | ||
token: ${{ secrets.GITHUB_TOKEN }} | ||
checkName: Travis CI - Pull Request | ||
ref: ${{ github.event.pull_request.head.sha || github.sha }} | ||
intervalSeconds: 10 | ||
timeoutSeconds: 3600 |
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.
Unfortunately, I expect the Travis CI check to fail every now and then (appart from the timeout being way too short for a Travis CI build).
This should really be a different workflow, possibly triggered by the checks being updated on main ?
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 different workflow should be fine, but it's harder to test since it can only run after merging, see https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
You could extract it to a separate workflow afterwards.
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.
It's fine to leave this here at the moment as you're saying.
It shouldn't be to hard to split with the deployment script being a separate bash script.
- name: Deploy | ||
if: steps.wait-for-travis.outputs.conclusion == 'success' | ||
run: ./deploy_multi_platform.sh | ||
|
||
- name: Error on failure | ||
if: steps.wait-for-travis.outputs.conclusion != 'success' | ||
run: exit 1 |
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.
maybe if this was a single step, the workflow could be re-run with failing steps only. This would require a manual action though hence I still prefer to have a separate workflow triggered on check updates if possible (only need to worry about Travis CI mostly in that case).
#1306