ci: Add github action to publish docker images #26136
Draft
+630
−168
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Reviewer's GuideThis PR refactors the CI by extracting Docker image publishing into a dedicated reusable workflow and updating the release-publish pipeline to invoke it, while also patching the Ubuntu dependency Dockerfile for ARM64 support. Class diagram for workflow job structure after refactorclassDiagram
class ReleasePublishWorkflow {
+publish-maven-artifacts
+publish-release-tag
+publish-docker-images
+publish-docs
}
class PublishDockerImagesWorkflow {
+prepare
+publish-dependency-image
+create-dependency-manifest
+publish-presto-image
+publish-prestissimo-image
+create-prestissimo-manifest
}
ReleasePublishWorkflow --> PublishDockerImagesWorkflow : uses
Flow diagram for ARM64 support in Ubuntu dependency Dockerfileflowchart TD
A["Start Docker build (ubuntu-22.04-dependency.dockerfile)"] --> B["Check architecture: dpkg --print-architecture"]
B -->|arm64| C["Install gcc-12 and g++-12 via PPA"]
B -->|not arm64| D["Skip ARM64-specific install"]
C --> E["Continue with build"]
D --> E
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Contributor
Author
|
@sourcery-ai review |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
Blocking issues:
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
General comments:
- Consider making the concurrency group dynamic (e.g. including
${{ inputs.branch_or_tag }}or${{ inputs.os }}) so dispatches for different branches or OSes don’t block each other. - You could simplify the Docker buildx/login/tag/push steps by using docker/build-push-action@v3 instead of scripting each step manually.
- Add a cache step for Maven dependencies (e.g. actions/cache on ~/.m2) to speed up the version extraction and submodule build processes.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider making the concurrency group dynamic (e.g. including `${{ inputs.branch_or_tag }}` or `${{ inputs.os }}`) so dispatches for different branches or OSes don’t block each other.
- You could simplify the Docker buildx/login/tag/push steps by using docker/build-push-action@v3 instead of scripting each step manually.
- Add a cache step for Maven dependencies (e.g. actions/cache on ~/.m2) to speed up the version extraction and submodule build processes.
## Individual Comments
### Comment 1
<location> `.github/workflows/publish-dependency-image.yml:74-78` </location>
<code_context>
+ - name: Checkout submodules
+ run: |
+ df -h
+ cd presto-native-execution && make submodules
+ echo "COMMIT_SHA=$(git rev-parse --short HEAD)" >> $GITHUB_ENV
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Check for submodule update failures to avoid silent errors.
Add 'set -e' or check the exit code to ensure the script fails if submodule updates do not succeed.
```suggestion
- name: Checkout submodules
run: |
set -e
df -h
cd presto-native-execution && make submodules
echo "COMMIT_SHA=$(git rev-parse --short HEAD)" >> $GITHUB_ENV
```
</issue_to_address>
### Comment 2
<location> `.github/workflows/publish-dependency-image.yml:82-91` </location>
<code_context>
+
+ - name: Extract version
+ run: |
+ VERSION=$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout)
+ echo "Raw version: $VERSION"
+
+ if [[ "$VERSION" == *"-SNAPSHOT" ]]; then
+ # Remove -SNAPSHOT and append commit SHA
+ CLEAN_VERSION=${VERSION%-SNAPSHOT}
+ TAG_VERSION="${CLEAN_VERSION}-${COMMIT_SHA}"
+ echo "SNAPSHOT version detected, using: $TAG_VERSION"
+ else
+ TAG_VERSION="$VERSION"
+ echo "Release version detected, using: $TAG_VERSION"
+ fi
+
+ echo "VERSION=$TAG_VERSION" >> $GITHUB_ENV
+
+ - name: Login to DockerHub
</code_context>
<issue_to_address>
**issue (bug_risk):** Handle possible mvn command failures to prevent propagating invalid version values.
Check if VERSION is set after running the mvn command, and fail the workflow if it is empty to prevent publishing images with invalid tags.
</issue_to_address>
### Comment 3
<location> `.github/workflows/publish-dependency-image.yml:109-112` </location>
<code_context>
+
+ - name: Set up builder
+ run: |
+ docker buildx create --name container --use
+ docker buildx inspect --bootstrap
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Avoid creating a new buildx builder if one already exists.
Creating a builder with a fixed name can lead to conflicts during retries or concurrent runs. Check for an existing builder before creating one, or use a unique name for each run.
```suggestion
- name: Set up builder
run: |
BUILDER_NAME="container-${GITHUB_RUN_ID}"
if ! docker buildx inspect "$BUILDER_NAME" > /dev/null 2>&1; then
docker buildx create --name "$BUILDER_NAME" --use
else
docker buildx use "$BUILDER_NAME"
fi
docker buildx inspect --bootstrap
```
</issue_to_address>
### Comment 4
<location> `.github/workflows/publish-dependency-image.yml:147-157` </location>
<code_context>
+
+ - name: Publish image
+ run: |
+ docker tag ${{ env.LOCAL_IMAGE_TAG }} ${{ env.IMAGE_TAG }}
+ docker push ${{ env.IMAGE_TAG }}
+
+ if [[ "${{ inputs.tag_latest }}" == "true" ]]; then
+ LATEST_TAG="${{ env.ORG_NAME }}/${{ env.IMAGE_NAME }}:${{ inputs.os }}-${{ matrix.arch }}-latest"
+ docker tag ${{ env.LOCAL_IMAGE_TAG }} ${LATEST_TAG}
+ docker push ${LATEST_TAG}
+ echo "Tagged and pushed as latest: ${LATEST_TAG}"
+ fi
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider adding error handling for docker push failures.
To prevent silent failures, ensure the workflow stops if 'docker push' fails by using 'set -e' or explicitly checking the exit code.
```suggestion
- name: Publish image
run: |
set -e
docker tag ${{ env.LOCAL_IMAGE_TAG }} ${{ env.IMAGE_TAG }}
docker push ${{ env.IMAGE_TAG }}
if [[ "${{ inputs.tag_latest }}" == "true" ]]; then
LATEST_TAG="${{ env.ORG_NAME }}/${{ env.IMAGE_NAME }}:${{ inputs.os }}-${{ matrix.arch }}-latest"
docker tag ${{ env.LOCAL_IMAGE_TAG }} ${LATEST_TAG}
docker push ${LATEST_TAG}
echo "Tagged and pushed as latest: ${LATEST_TAG}"
fi
```
</issue_to_address>
### Comment 5
<location> `.github/workflows/publish-dependency-image.yml:98` </location>
<code_context>
uses: docker/login-action@v3
</code_context>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Comment 6
<location> `.github/workflows/publish-dependency-image.yml:104` </location>
<code_context>
uses: docker/setup-qemu-action@v3
</code_context>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Comment 7
<location> `.github/workflows/publish-dependency-image.yml:107` </location>
<code_context>
uses: docker/setup-buildx-action@v3
</code_context>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
unidevel
force-pushed
the
publish-images
branch
from
e947e6b to
9c40d85
Compare
Contributor
Author
|
@sourcery-ai review |
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
Blocking issues:
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
General comments:
- Consider leveraging docker/build-push-action for multi-arch builds instead of hand-rolling buildx and push steps to simplify the workflow.
- In the Dockerfile, group your apt update+install commands into single RUN layers and extract the ARM-specific gcc-12 setup into a script to improve readability and layer caching.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider leveraging docker/build-push-action for multi-arch builds instead of hand-rolling buildx and push steps to simplify the workflow.
- In the Dockerfile, group your apt update+install commands into single RUN layers and extract the ARM-specific gcc-12 setup into a script to improve readability and layer caching.
## Individual Comments
### Comment 1
<location> `.github/workflows/publish-dependency-image.yml:104` </location>
<code_context>
uses: docker/login-action@v3
</code_context>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Comment 2
<location> `.github/workflows/publish-dependency-image.yml:110` </location>
<code_context>
uses: docker/setup-qemu-action@v3
</code_context>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Comment 3
<location> `.github/workflows/publish-dependency-image.yml:113` </location>
<code_context>
uses: docker/setup-buildx-action@v3
</code_context>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
unidevel
force-pushed
the
publish-images
branch
from
d308fae to
9bd49ab
Compare
Contributor
Author
|
@sourcery-ai review |
prestodb-ci
requested review from
a team and
BryanCutler
and removed request for
a team
unidevel
changed the title
Contributor
Author
|
@sourcery-ai dismiss |
sourcery-ai
bot
dismissed stale reviews from themself
Automated Sourcery review dismissed.
BryanCutler
reviewed
Sep 25, 2025
| (cd build && ../scripts/setup-ubuntu.sh && \ | ||
| apt install -y rpm && \ | ||
| (cd build && apt update && apt install -y rpm sudo && \ | ||
| ../scripts/setup-ubuntu.sh && \ |
Contributor
There was a problem hiding this comment.
The setup-ubuntu.sh will perform an update, are you trying to install a sudo package?
I'm not sure what you are trying to do here, can you explain the reason for changing this?
Contributor
Author
There was a problem hiding this comment.
Because the file scripts/setup-ubuntu.sh has a bug, should use $SUDO in the script.
And this dependency is only used for dev purpose.
Contributor
Author
There was a problem hiding this comment.
There is a PR to fix this, but not merged.
Contributor
There was a problem hiding this comment.
I suppose we can fix this once the PR was merged and is available through the submodule. Maybe open an issue for that so we don't forget?
czentgr
reviewed
Sep 29, 2025
| (cd build && ../scripts/setup-ubuntu.sh && \ | ||
| apt install -y rpm && \ | ||
| (cd build && apt update && apt install -y rpm sudo && \ | ||
| ../scripts/setup-ubuntu.sh && \ |
Contributor
There was a problem hiding this comment.
I suppose we can fix this once the PR was merged and is available through the submodule. Maybe open an issue for that so we don't forget?
unidevel
changed the title
unidevel
force-pushed
the
publish-images
branch
from
9bd49ab to
f13012a
Compare
BryanCutler
previously approved these changes
Oct 9, 2025
Contributor
BryanCutler
left a comment
BryanCutler
left a comment
There was a problem hiding this comment.
Looks ok to me with the followup issue once fixed in Velox
Contributor
Author
|
Thanks @czentgr and @BryanCutler , I'll update this after the velox fix merged. |
Contributor
Author
|
Seem the sudo fix merged, let me update the script and do the tests |
unidevel
force-pushed
the
publish-images
branch
from
f13012a to
d32c769
Compare
unidevel
force-pushed
the
publish-images
branch
2 times, most recently
from
b6c75e6 to
897b47b
Compare
Contributor
Author
6 tasks
unidevel
force-pushed
the
publish-images
branch
3 times, most recently
from
4d328ba to
87be793
Compare
unidevel
changed the title
Contributor
Author
|
@sourcery-ai review |
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- The publish-dependency-image.yml, publish-presto-image.yml, and publish-prestissimo-image.yml workflows share a lot of identical steps—consider merging them into a single reusable workflow with parameters to reduce duplication and maintenance overhead.
- The publish-presto-image workflow still offers 'ubuntu' as an OS choice but immediately errors out on ubuntu; either remove that option or gate it at the trigger level to avoid confusing failures.
- There are trailing "# Made with Bob" comments in several workflow files—these generator artifacts can be removed to keep the files clean.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The publish-dependency-image.yml, publish-presto-image.yml, and publish-prestissimo-image.yml workflows share a lot of identical steps—consider merging them into a single reusable workflow with parameters to reduce duplication and maintenance overhead.
- The publish-presto-image workflow still offers 'ubuntu' as an OS choice but immediately errors out on ubuntu; either remove that option or gate it at the trigger level to avoid confusing failures.
- There are trailing "# Made with Bob" comments in several workflow files—these generator artifacts can be removed to keep the files clean.
## Individual Comments
### Comment 1
<location> `.github/workflows/publish-presto-image.yml:227-230` </location>
<code_context>
+ MANIFEST_TAG="${ORG_NAME}/${IMAGE_NAME}:${VERSION}${TAG_SUFFIX}"
+
+ echo "Creating manifest: ${MANIFEST_TAG}"
+ docker manifest create ${MANIFEST_TAG} \
+ ${MANIFEST_TAG}@$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "amd64").digest') \
+ ${MANIFEST_TAG}@$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "arm64").digest') \
+ ${MANIFEST_TAG}@$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "ppc64le").digest')
+
+ docker manifest push ${MANIFEST_TAG}
</code_context>
<issue_to_address>
**suggestion:** Using jq to extract digests for manifest creation may fail if images are not yet available.
Add error handling or pre-checks to verify all required images are available before running manifest creation to prevent failures.
Suggested implementation:
```
# Create manifest for the versioned tag
MANIFEST_TAG="${ORG_NAME}/${IMAGE_NAME}:${VERSION}${TAG_SUFFIX}"
AMD64_DIGEST=$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "amd64").digest')
ARM64_DIGEST=$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "arm64").digest')
PPC64LE_DIGEST=$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "ppc64le").digest')
if [[ -z "${AMD64_DIGEST}" || -z "${ARM64_DIGEST}" || -z "${PPC64LE_DIGEST}" ]]; then
echo "Error: One or more required image digests are missing for manifest creation."
echo "amd64 digest: ${AMD64_DIGEST}"
echo "arm64 digest: ${ARM64_DIGEST}"
echo "ppc64le digest: ${PPC64LE_DIGEST}"
exit 1
fi
echo "Creating manifest: ${MANIFEST_TAG}"
docker manifest create ${MANIFEST_TAG} \
${MANIFEST_TAG}@${AMD64_DIGEST} \
${MANIFEST_TAG}@${ARM64_DIGEST} \
${MANIFEST_TAG}@${PPC64LE_DIGEST}
docker manifest push ${MANIFEST_TAG}
```
```
# Create latest manifest if requested
if [[ "${{ inputs.tag_latest }}" == "true" ]]; then
LATEST_MANIFEST="${ORG_NAME}/${IMAGE_NAME}:latest"
# Reuse the digests from above, or re-fetch if needed
if [[ -z "${AMD64_DIGEST}" || -z "${ARM64_DIGEST}" || -z "${PPC64LE_DIGEST}" ]]; then
AMD64_DIGEST=$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "amd64").digest')
ARM64_DIGEST=$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "arm64").digest')
PPC64LE_DIGEST=$(docker manifest inspect ${MANIFEST_TAG} | jq -r '.manifests[] | select(.platform.architecture == "ppc64le").digest')
fi
if [[ -z "${AMD64_DIGEST}" || -z "${ARM64_DIGEST}" || -z "${PPC64LE_DIGEST}" ]]; then
echo "Error: One or more required image digests are missing for latest manifest creation."
echo "amd64 digest: ${AMD64_DIGEST}"
echo "arm64 digest: ${ARM64_DIGEST}"
echo "ppc64le digest: ${PPC64LE_DIGEST}"
exit 1
fi
echo "Creating latest manifest: ${LATEST_MANIFEST}"
docker manifest create ${LATEST_MANIFEST} \
${MANIFEST_TAG}@${AMD64_DIGEST} \
${MANIFEST_TAG}@${ARM64_DIGEST} \
${MANIFEST_TAG}@${PPC64LE_DIGEST}
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Contributor
Author
|
@sourcery-ai review |
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- The new publish-docker-images.yml is over 600 lines and combines multiple jobs—consider refactoring shared steps into composite actions or splitting it into smaller workflow files to improve readability and maintainability.
- Add caching for Maven dependencies (actions/cache) and Docker buildx layer caching to speed up builds and reduce load on CI runners.
- The concurrency group is currently a static string (‘publish-docker-images’), which can block parallel releases—consider incorporating the branch_or_tag input into the group key so different releases don’t cancel each other.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The new publish-docker-images.yml is over 600 lines and combines multiple jobs—consider refactoring shared steps into composite actions or splitting it into smaller workflow files to improve readability and maintainability.
- Add caching for Maven dependencies (actions/cache) and Docker buildx layer caching to speed up builds and reduce load on CI runners.
- The concurrency group is currently a static string (‘publish-docker-images’), which can block parallel releases—consider incorporating the branch_or_tag input into the group key so different releases don’t cancel each other.
## Individual Comments
### Comment 1
<location> `.github/workflows/publish-docker-images.yml:546-555` </location>
<code_context>
+ fi
+
+ # Build the prestissimo image using standard Docker build
+ docker build \
+ --build-arg EXTRA_CMAKE_FLAGS="$EXTRA_CMAKE_FLAGS" \
+ --build-arg DEPENDENCY_IMAGE=${{ env.DEPENDENCY_IMAGE }} \
+ --build-arg BASE_IMAGE=$BASE_IMAGE \
+ --build-arg OSNAME=${{ inputs.os }} \
+ --build-arg BUILD_TYPE=Release \
+ --build-arg NUM_THREADS=2 \
+ ${BUILD_ARGS} \
+ -f scripts/dockerfiles/prestissimo-runtime.dockerfile \
+ -t ${{ env.IMAGE_TAG }} \
+ .
+
</code_context>
<issue_to_address>
**suggestion:** Direct use of docker build for prestissimo image may limit multi-arch support compared to buildx.
Consider using Buildx instead of 'docker build' for the prestissimo image to enable multi-arch support and maintain consistency with other image builds.
Suggested implementation:
```
# Build the prestissimo image using Docker Buildx for multi-arch support
docker buildx build \
--build-arg EXTRA_CMAKE_FLAGS="$EXTRA_CMAKE_FLAGS" \
--build-arg DEPENDENCY_IMAGE=${{ env.DEPENDENCY_IMAGE }} \
--build-arg BASE_IMAGE=$BASE_IMAGE \
--build-arg OSNAME=${{ inputs.os }} \
--build-arg BUILD_TYPE=Release \
--build-arg NUM_THREADS=2 \
${BUILD_ARGS} \
--platform ${{ matrix.arch }} \
-f scripts/dockerfiles/prestissimo-runtime.dockerfile \
-t ${{ env.IMAGE_TAG }} \
--push \
.
```
- Ensure that a Buildx builder is set up and available in the workflow before this step. If not, add a step to create and use a Buildx builder.
- Confirm that `${{ matrix.arch }}` resolves to a valid platform string (e.g., `linux/amd64`, `linux/arm64`). If not, map it accordingly.
- If you do not want to push the image immediately, remove the `--push` flag.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
unidevel
force-pushed
the
publish-images
branch
3 times, most recently
from
3c30e7f to
eb158d1
Compare
Contributor
Author
|
Convert to draft since need testing and refactoring. |
unidevel
force-pushed
the
publish-images
branch
2 times, most recently
from
95fdd06 to
f0de13e
Compare
unidevel
force-pushed
the
publish-images
branch
from
f0de13e to
d2feeb9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Add the action to build and publish the docker images include presto java images(amd64/arm64/ppc64le), prestissimo dependency images(amd64/arm64), prestissimo runtime(amd64/arm64)
Also update release action to call this
Motivation and Context
N/A
Impact
New release
Test Plan
Release action(centos images): https://github.com/unix280/presto/actions/runs/19377487489
Publish ubuntu images: https://github.com/unix280/presto/actions/runs/19395470075
Contributor checklist
Release Notes
Please follow release notes guidelines and fill in the release notes below.