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

Refactor how/where ko:// is handled. (#153) #1

Merged
merged 1 commit into from
Apr 30, 2020

Conversation

albertomilan
Copy link
Owner

This change more or less completely changes how ko:// is handled internally to ko, but the user-facing changes should only be net-positive. ko:// was previously stripped at the highest level, and the build logic was unaware, which had some undesirable diagnostic/functional implications that are collectively addressed in this change.

With this change, the ko:// prefix is preserved and passed to the build logic, which internally parses a new reference type (this was useful to have Go's type checker find all of the places that needed fixing). The main functional differences are:

  1. If a reference is prefixed with ko:// we will now fail fast in IsSupportedReference regardless of whether --strict is passed.
  2. If a reference is prefixed with ko:// it will bypass the prefix check, which allows the use of ko://github.com/another/repo that references a vendored binary package.

For 2. the absence of the module prefix causes the filtering logic Jon introduced to avoid the reference. This was critical for efficiency when ko:// isn't around because we feed every string in the yaml through it, but when the user has explicitly decorated things it's the perfect thing to be sensitive to.

Fixes: ko-build#146
Fixes: ko-build#152

This change more or less completely changes how `ko://` is handled internally to `ko`, but the user-facing changes should only be net-positive.  `ko://` was previously stripped at the highest level, and the build logic was unaware, which had some undesirable diagnostic/functional implications that are collectively addressed in this change.

With this change, the `ko://` prefix is preserved and passed to the build logic, which internally parses a new `reference` type (this was useful to have Go's type checker find all of the places that needed fixing).  The main functional differences are:
1. If a reference is prefixed with `ko://` we will now fail fast in `IsSupportedReference` regardless of whether `--strict` is passed.
2. If a reference is prefixed with `ko://` it will bypass the prefix check, which allows the use of `ko://github.com/another/repo` that references a vendored binary package.

For `2.` the absence of the module prefix causes the filtering logic Jon introduced to avoid the reference.  This was critical for efficiency when `ko://` isn't around because we feed every string in the yaml through it, but when the user has explicitly decorated things it's the perfect thing to be sensitive to.

Fixes: #146
Fixes: #152
@albertomilan albertomilan merged commit c10801c into albertomilan:master Apr 30, 2020
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.

vendor paths are broken with go modules IsSupportedReference could surface better errors
2 participants