-
Notifications
You must be signed in to change notification settings - Fork 16
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
Support Google Container Registry #26
Conversation
…fore max-age (those are done via GCS TTL policy)
Hey, thanks for the PR! Sorry for no reply on #24 -- has been a bit crazy :S I think this does make sense in the same plugin. I was originally thinking it would be easier to have a separate plugin, but with the same interface. However, one thing to keep in mind would be testing -- we don't use GCR so we'd have to rely on the bats 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.
Looks great, would be happy to accept this with the tests. I reckon more overlap/same interface the better
Co-authored-by: Zac Sims <zsims@users.noreply.github.com>
…rd dockerfile location, OR file path separators...
(This commit stream is me iterating a docker build on a Windows machine, and I'm having a great time, clearly) |
hooks/pre-command
Outdated
echoerr '--- Computing tag' | ||
|
||
echoerr 'DOCKERFILE' | ||
echoerr "+ ${docker_file}:${target:-<target>}" | ||
echoerr "+ ${docker_file}:${target:-"<target>"}" |
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.
Are these extra quotes required?
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.
No, that's muscle memory on my part. I tend to always enclose strings in quotes and variables inside {} because it's easier than remembering where it will be necessary and where it won't be necessary, compared to just reflexively doing it everywhere.
@zsims please take another look? I've added test coverage, and intend to add 2 more to |
I reckon this is now ready for re-review. Since last time, I have
That takes us from 2 tests to 17. I never knew it was so comparatively straightforward to write bash test coverage, so I'm really grateful for the lesson! In terms of backwards compatibility, is there anything you'd like me to do (though, probably if so, in a follow-up - this PR has ballooned!). Things I thought of:
|
(The tests run and pass on Windows and macOS hosts) |
Sounds like a rename is a good idea! If you trust seek-oss enough to not use SHA-pinned plugins, then perhaps it's probably okay to let the name sit there available for another repo to steal back at some point? |
I'm a very trusting sort. I'd actually forgotten that it's an commercial org :) |
😁 |
Hey, thanks for this @petemounce! @zsims has subbed out but I will try to review soon 🙏 RE: the rename, I think the least surprising way would be to fork this repo then archive the current one. |
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 for your patience! It's been pretty full-on here over the past few weeks. This is a massive improvement and the tests are awesome 🙏
Just have a few nits that should be easily resolved. Let me know if you're busy and I can run with it.
echoerr "registry-hostname had no value, defaulting to gcr.io" | ||
BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_REGISTRY_HOSTNAME="gcr.io" | ||
fi | ||
echo "${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_REGISTRY_HOSTNAME}/${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_GCP_PROJECT}/${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_ECR_NAME:-"$(get_default_image_name)"}" |
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.
Ugh. Not for this PR, but we should definitely have a generic alias for this option as you've suggested.
Note that the README says that this is an ECR-specific option, so we should either update it or drop this logic from here until we have that image-name
.
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.
Let me know which way you'd prefer to go on this one ^ @petemounce
Apart from that, looks all ready to merge!
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 think I'd prefer to leave this as-is within this PR, and iterate afterwards.
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.
Actually, wait - I'm not sure I follow what you're suggesting. Please would you elaborate?
GCR URIs take the form https://{host}/{gcp-project}/{container}:{tag} - so, actually, I think
container` is the equivalent to ECR's repository now that I think about this more freshly.
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 think container is the equivalent to ECR's repository
Yep, looks that way to me too. Happy to iterate on it.
Above I was thinking that we should document that ecr-name
affects the GCR configuration, but it's probably not necessary given it's optional and we'd probably want to fix up the name in future.
Co-authored-by: Ryan Ling <ryan@outlook.com.au>
echoerr "registry-hostname had no value, defaulting to gcr.io" | ||
BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_REGISTRY_HOSTNAME="gcr.io" | ||
fi | ||
echo "${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_REGISTRY_HOSTNAME}/${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_GCP_PROJECT}/${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_ECR_NAME:-"$(get_default_image_name)"}" |
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.
Let me know which way you'd prefer to go on this one ^ @petemounce
Apart from that, looks all ready to merge!
Not sure whether this will be a welcome addition (no reply inside #24), but I decided to make a start since I'll be able to use this via our fork either way.
What's going on here:
hooks/pre-command
. This will fail with an error if the plugin is misconfigured.Initial commit is just this. I'm still interested to see whether the maintainers (I assume @zsims ?) are interested in this addition.
Still to-do (whether that's this PR or followups)