-
Notifications
You must be signed in to change notification settings - Fork 4
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
Debug/v0.1.x #4
Debug/v0.1.x #4
Conversation
This commit inits the deploy-gke container action. It utlizes the gke-deploy CLI image to deploy an existing image to a GKE cluster. The integration test, documentation and CI setup are included within this initial commit.
This commit debugs the integration workflow platform failure. Will be reverted once it resolves.
usually means we're trying to run the wrong binary (e.g. Mac binary on Linux or arm on amd). |
Thanks for the eyes on this @sethvargo (and also for the help with merging the CI earlier) I've been looking into this platform arch mismatch - from the output it seems to be building and running at the same platform (x86), which made me confused:
And when I tried to tag the GHA and use it as a released version i.e. https://github.com/JeromeJu/gar-upload-container as the POC which is used as May I ask what's the point that I should look at? - my suspicion is it relates with |
|
||
USER root | ||
|
||
COPY entrypoint.sh /entrypoint.sh |
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.
You might need to mark this file as executable, especially since you're running as root.
Thanks @sethvargo for the PR for granting the WIF access - Now the authentication works but the deploy process failed with the service not being able to expose its external IP with the specified port. I've been taking some time looking into this (a network issue IIUC) and tried to debug. The failed workflow has the following logs:
Related source code of the image: Some attempts I've tried but didn't work:
|
Hi @JeromeJu - this is likely an organizational policy constraint. We do not allow services to allow arbitrary public ingress from the Internet in our test environment. Is exposing via a public IP required for testing? |
Thanks for the pointer, I removed the expose port given this org policy and also as it is really just a feature dependency on the upstream. |
Closing in light of #5 |
This commit debugs the integration workflow platform failure.
Will be reverted once it resolves.