-
Notifications
You must be signed in to change notification settings - Fork 80
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
Publish Release Images #15013
Publish Release Images #15013
Conversation
df099cc
to
b38aaf8
Compare
Is it normal to distribute docker images through github container registry? I thought dockerhub was the norm. |
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.
LGTM!
Only complaint is that this is not really a release docker image, as it has build dependencies. However, I see you've documented that and filed an issue to fix.
I do think it is the norm and definitely more appropriate for the current state of these images. We can always change the destination registry at a later time. |
2f938f2
to
a501f7c
Compare
… Release Images (#15371) ### Ticket #12496 #12495 (describes agreed upon naming scheme) ### Problem description This is an empty workflow that allows for additional testing before the main set of changes is merged from #15013 ### What's changed Added a new NO-OP workflow ### Checklist - [x] Post commit CI passes - [ ] Blackhole Post commit (if applicable) - [ ] Model regression CI testing passes (if applicable) - [ ] Device performance regression CI testing passes (if applicable) - [ ] New/Existing tests provide coverage for changes
@@ -86,7 +86,7 @@ runs: | |||
${{ inputs.device }} | |||
-w ${{ github.workspace }} | |||
run: | | |||
if [ ${{ inputs.install_wheel }} ]; then | |||
if [ "${{ inputs.install_wheel }}" == "true" ]; then |
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.
Fix the issue where the wheel was always installed.
@@ -24,8 +24,8 @@ runs: | |||
- name: Determine Full Docker Image Tag | |||
shell: bash | |||
run: | | |||
echo "TT_METAL_DOCKER_IMAGE_TAG=ghcr.io/${{ github.repository }}/tt-metalium/${{ inputs.image }}:${{ env.IMAGE_TAG }}" >> $GITHUB_ENV | |||
echo "TT_METAL_REF_IMAGE_TAG=ghcr.io/${{ github.repository }}/tt-metalium/${{ inputs.image }}:latest" >> $GITHUB_ENV |
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.
This does not allow us to use images that follow the convention outlined in:
#12495
i.e.
tt-metalium-{OS}-{ARCH}-release/grayskull
784f01d
to
cfea754
Compare
Should we update the latest tag only when the major release happens?
|
arch: wormhole_b0, | ||
runs-on: ["cloud-virtual-machine", "N150", "in-service"], | ||
cmd: pytest tests/end_to_end_tests, | ||
} |
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.
Why not N300?
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.
I picked the machine that seemed to have a lesser demand.
…e is not being passed properly for release image This reverts commit 845ddf8.
Ticket
#12496
#12495 (describes agreed upon naming scheme)
Problem description
Allow users to get started with TT-Metal stack within two command lines.
What's changed
Add a job for the package release to also build/push a release image.
TODO:
Checklist