Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[v0.11] Adapt qpext workflow for OpenDataHub #68

Merged
merged 1 commit into from
Sep 5, 2023
Merged

[v0.11] Adapt qpext workflow for OpenDataHub #68

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 15 additions & 8 deletions .github/workflows/qpext-docker-publish.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@ on:
# Publish `master` as Docker `latest` image.
branches:
- master
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this still needed? This PR is for the release branch.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not needed here. Although, I think, it also doesn't hurt.

If it is noisy, I can remove it.

- release-*

# Publish `v1.2.3` tags as releases.
tags:
Expand All @@ -14,7 +15,7 @@ on:
pull_request:

env:
IMAGE_NAME: qpext
IMAGE_NAME: kserve-qpext

jobs:
# Run tests.
Expand Down Expand Up @@ -53,15 +54,16 @@ jobs:
- name: Setup Docker Buildx
uses: docker/setup-buildx-action@v2

- name: Login to DockerHub
- name: Login to Quay
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_USER }}
password: ${{ secrets.DOCKER_PASSWORD }}
registry: quay.io
username: ${{ secrets.QUAY_USER }}
password: ${{ secrets.QUAY_PASSWORD }}

- name: export version variable
run: |
IMAGE_ID=kserve/$IMAGE_NAME
IMAGE_ID=quay.io/${{ vars.QUAY_OWNER }}/$IMAGE_NAME

# Change all uppercase to lowercase
IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
Expand All @@ -74,9 +76,14 @@ jobs:

# Use Docker `latest` tag convention
[ "$VERSION" == "master" ] && VERSION=latest
[[ "$VERSION" =~ ^release- ]] && VERSION=$(echo $VERSION | sed 's/^release-//')-latest
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so 0.11 release branch will use 0.11-latest ?
I think retag it to 2 tags: 0.11-$COMMIT_SHA and 0.11 . then quay.io will show these 2 images are the same.
WDYT?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so 0.11 release branch will use 0.11-latest ?

Yes.

I think retag it to 2 tags: 0.11-$COMMIT_SHA and 0.11 . then quay.io will show these 2 images are the same.

Would it be useful? I don't see a reason for accumulating images.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The image manifest on quay should include git ref if we don't include it in the image tag itself, but it's definitely easier for lookup purposes to do commit sha

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The image manifest on quay should include git ref if we don't include it in the image tag itself, but it's definitely easier for lookup purposes to do commit sha

The -latest suffix is the typical docker nomenclature. I'd think it maps "naturally". The v0.11-latest tag would map to release-v0.11 git ref.

If we strictly want a git-ref, I can create both the git-ref tag and the docker-friendly tag: release-v0.11 and v0.11-latest.

But, then, I'm still not sure about the tag carrying the SHA, as that would mean accumulating images.

Copy link
Author

@israel-hdez israel-hdez Aug 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still thinking on the tag with the SHA.

Do we really need it? Being ODH, I don't see a hard req for it.


echo VERSION=$VERSION >> $GITHUB_ENV
echo IMAGE_ID=$IMAGE_ID >> $GITHUB_ENV
TAGS=$IMAGE_ID:$VERSION

# If a vX.Y.Z release is being built, also update the vX.Y tag.
[[ "$VERSION" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]] && TAGS=$TAGS,$IMAGE_ID:$(echo $VERSION | sed 's/\(.*\)\.[[:digit:]]\+$/\1/')

echo CONTAINER_TAGS=$TAGS >> $GITHUB_ENV

- name: Build and push
uses: docker/build-push-action@v3
Expand All @@ -85,4 +92,4 @@ jobs:
context: "{{defaultContext}}:qpext"
file: qpext.Dockerfile
push: true
tags: ${{ env.IMAGE_ID }}:${{ env.VERSION }}
tags: ${{ env.CONTAINER_TAGS }}
Loading