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.

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

Merged
merged 27 commits into from
Jul 9, 2020

Conversation

petemounce
Copy link
Contributor

@petemounce petemounce commented May 22, 2020

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:

  • Extracted the ECR-specific functions to the ecr-registry-provider.bash include.
    • They're verbatim implementations, but a couple had their names changed since there'll be GCR-specific implementations so I made the names generalised.
  • Introduced the provider-specific include at the top of 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)

  • docs updates
  • GCR implementation
    • BATS for GCR implementation

@zsims
Copy link
Contributor

zsims commented May 25, 2020

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.

Copy link
Contributor

@zsims zsims left a 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

hooks/lib/ecr-registry-provider.bash Show resolved Hide resolved
hooks/lib/gcr-registry-provider.bash Show resolved Hide resolved
hooks/lib/stdlib.bash Outdated Show resolved Hide resolved
@petemounce
Copy link
Contributor Author

(This commit stream is me iterating a docker build on a Windows machine, and I'm having a great time, clearly)

echoerr '--- Computing tag'

echoerr 'DOCKERFILE'
echoerr "+ ${docker_file}:${target:-<target>}"
echoerr "+ ${docker_file}:${target:-"<target>"}"
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@petemounce
Copy link
Contributor Author

@zsims please take another look? I've added test coverage, and intend to add 2 more to pre-command.bats.

@petemounce
Copy link
Contributor Author

petemounce commented Jun 15, 2020

@zsims Please also see #27?

I reckon this is now ready for re-review. Since last time, I have

  • moved the functions from hooks/pre-command to hooks/lib/stdlib.bash to move them out the way. At the time, I'd hoped it was possible to stub out bash functions, but I later didn't find out how, so ...
  • I added hooks/lib/stub-registry-provider.bash which makes stubs for things so that the tests/pre-command.bats didn't have to repeat...
  • ... the test coverage I wrote in tests/stdlib.bash
  • added test coverage tests/gcr-registry-provider.bats

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:

  • make additional-build-args an array instead of a string, since that simplifies that bit of script that glues that onto the end of the docker build down to "${BUILDKITE_PLUGIN_DOCKER_ECR_CACHE_ADDITIONAL_BUILD_ARGS[@]}"
  • add .pre-commit-config.yaml with shellcheck and shfmt and some other quality-of-life stuff (see pre-commit.com)
  • make the target be an arg to compute_tag instead of leaking in from outer scope
  • Add a plugin property image-name to replace ecr-name
    • ... but maintain backwards compatibility by coalescing back to ecr-name's env var
  • Maybe talk about renaming the repository to docker-cache-buildkite-plugin?
    • That has some entertaining injection security implications, however - github will redirect requests both UI and clone to the new name from the old name. However, if someone makes a new replacement docker-ecr-cache-buildkite-plugin with the same tags as here, that will silently man-in-the-middle peoples' pipelines.
    • perhaps @lox or @toolmantim might like to give some advice on what is best to do here?

@petemounce
Copy link
Contributor Author

(The tests run and pass on Windows and macOS hosts)

@toolmantim
Copy link

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?

@petemounce
Copy link
Contributor Author

I'm a very trusting sort. I'd actually forgotten that it's an commercial org :)

@toolmantim
Copy link

😁

@72636c
Copy link
Member

72636c commented Jun 18, 2020

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.

Copy link
Member

@72636c 72636c left a 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.

hooks/lib/stdlib.bash Show resolved Hide resolved
hooks/lib/stdlib.bash Outdated Show resolved Hide resolved
hooks/pre-command Show resolved Hide resolved
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)"}"
Copy link
Member

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.

Copy link
Member

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!

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

@72636c 72636c Jul 9, 2020

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.

hooks/pre-command Show resolved Hide resolved
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)"}"
Copy link
Member

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!

@72636c 72636c merged commit fb591eb into seek-oss:master Jul 9, 2020
@petemounce petemounce deleted the support-gcr-1 branch July 9, 2020 17:10
@petemounce petemounce restored the support-gcr-1 branch July 9, 2020 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants