-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Fix PostCommit XVR GoUsingJava Dataflow job #36757
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
Fix PostCommit XVR GoUsingJava Dataflow job #36757
Conversation
Summary of ChangesHello @aIbrahiim, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the reliability of the Docker image build and push process for Python containers within the Java Dataflow runner. It introduces comprehensive checks to ensure the required Docker image is available locally, from the build cache, or from the registry before attempting to push, thereby preventing failures due to missing images. Additionally, it refines the Docker push command for better compatibility and explicit configuration, specifically addressing a post-commit issue related to XVR Java Dataflow. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Changed CLOUDSDK_CONFIG to /tmp/gcloud as the original KUBELET_GCLOUD_CONFIG_PATH was pointing to a read only directory in the pod, so gcloud couldn't write its config files and was crashing with permission errors while /tmp/gcloud is writable and fixes the authentication issues |
|
Assigning reviewers: R: @liferoad for label build. Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #36757 +/- ##
=========================================
Coverage 56.96% 56.96%
Complexity 3456 3456
=========================================
Files 1223 1223
Lines 187539 187539
Branches 3586 3586
=========================================
Hits 106837 106837
Misses 77312 77312
Partials 3390 3390 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| } | ||
| imageExists = true | ||
| } catch (Exception e) { | ||
| println "Image ${defaultDockerImageName} not found locally: ${e.message}" |
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.
What caused this? We should fix the underlying cause that docker image not gets built. be able to build container successfully at once. This kind of fallback logic is generally not preferred
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 reason I added this try catch block was to address a specific error we were seeing in the logs:
The Docker build task (:sdks:python:container:py39:docker) was completing successfully, but when the subsequent docker inspect` command ran, the image wasn't found in the local Docker daemon. This happens because when using docker buildx with the docker container driver, the image is built into buildx's cache but isn't automatically loaded into the Docker daemons image store.
The fallback logic try to load the image from buildx cache using docker buildx build --output type=docker` which forces the image into the local Docker daemon. If that fails, it tries to pull from the registry .
| uses: ./.github/actions/setup-environment-action | ||
| with: | ||
| python-version: default | ||
| - name: Set up writable gcloud config directory |
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.
Other Dataflow XVR tests also push containers in order to run tests: https://github.com/apache/beam/blob/master/.github/workflows/beam_PostCommit_XVR_PythonUsingJava_Dataflow.yml
but what's the reason only this one requires environment setup in github action yaml file? In general we wish to keep GHA yaml minimum, and aims to make gradle target self contained so developers can test the target locally, or in different environment, not necessarily rely on GitHub Action runner to run.
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 reason this workflow needs the explicit CLOUDSDK_CONFIG setup is because we were hitting specific permission errors that weren't occurring in the PythonUsingJava workflow. The original KUBELET_GCLOUD_CONFIG_PATH points to a read only directory in the Kubernetes pod, causing gcloud to crash when trying to write its config files.
error from logs:
WARNING: Could not setup log file in /var/lib/kubelet/pods/.../volumes/kubernetes.io~empty-dir/gcloud/logs, (Error: Could not create directory [...] Permission denied.
ERROR: gcloud crashed (OperationalError): unable to open database file
denied: Permission "artifactregistry.repositories.uploadArtifacts" denied on resource "projects/apache-beam-testing/locations/us/repositories/us.gcr.io"
damccorm
left a comment
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.
Thanks!
Fixes: #30519
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, commentfixes #<ISSUE NUMBER>instead.CHANGES.mdwith noteworthy changes.See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)
See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.