-
Notifications
You must be signed in to change notification settings - Fork 408
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
Require ko://
prefix on all references
#158
Comments
I am +1 inside of yaml, but publish should still take a path without This will speed up some of the path searching too if you can skip over non- |
Anything that prevents the container image that we're trying to launch being something like github.com/vaikas/dump would be great imho. |
While we are at it, let's deprecate |
I'm going to try to knock these off this morning. I'll open a proper issue for the base outlining things so I can include it in the deprecation notice. |
ko://
prefix on all references
Fixes: ko-build#158 Fixes: ko-build#160
ko will start requiring this prefix in an upcoming release per ko-build/ko#158 Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
ko will start requiring this prefix in an upcoming release per ko-build/ko#158 Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
Fixes: ko-build#158 Fixes: ko-build#160
Deprecate and eliminate the use of unqualified references (e.g. no
ko://
).The initial heuristic-based approach was a bit too clever, and led to a lot of undesirable failure modes, which are really confusing to new users. With this change we will start to warn whenever we publish an image for an unprefixed import path, and stop building them in a coming release.
Dropping the heuristic approach will also speed up builds because the heuristic has gotten more expensive with the adoption of go modules.
The plan:
ko://
emit a warning linking to this issue.ko://
To suppress this warning
Prefix the import path with
ko://
, e.g.UPDATED to improve the main issue body. Original below. 👇
@imjasonh added support for
ko://
prefixed references a while ago, and I feel like there's been fairly steady adoption of this as projects have matured and folks have been bitten by the old guard heuristics (😬 mea culpa).I propose we start to emit warnings when we are fed references that ARE supported references, but that don't use
ko://
and cut a new release.cc @jonjohnsonjr @dprotaso
The text was updated successfully, but these errors were encountered: