Giters

ko-build / ko

Build and deploy Go applications

Home Page:https://ko.build

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Move to github.com/ko-build

imjasonh opened this issue · comments

commented

An incomplete list of steps, more or less in order:

  • create github.com/ko-build org
    • move this repo to github.com/ko-build (early September)
  • #749
    • set up ko.build vanity importpath redirect using <meta> tag
  • #1025
  • ghcr.io/google/ko image name change
    • ⚠️ GitHub will apparently not automatically redirect package requests; users will need to update their references to get future updates
  • GitHub Releases download links will apparently redirect, so long as https://github.com/google/ko is not recreated later!
  • rename K8s slack channel #ko-project to #ko-build (ref)
  • move https://github.com/imjasonh/setup-ko
    • update setup-ko to fetch released binaries from https://github.com/ko-build/ko/releases and go install ko.build@main
    • cut v0.6 not needed yet
    • GitHub will apparently redirect requests for imjasonh/setup-ko
  • https://github.com/chainguard-dev/terraform-provider-ko
    • update TF module release to point to new location, in new TF org

cc @mchmarny

If anybody thinks of anything that's missing, please let us know!

commented

Thanks for putting this together, Jason.

The Go releases section is little unclear. Are you saying that the v0.12 release will have to be done BEFORE the repo is moved or after... because this is all just go mod magic anyway and we can do this transparently under github.com/ko-build/ko?

Also, the lack of redirects on image pull requests is disappointing but kind of makes sense. Do we have a feel for the volume of unique pull sources we see on daily bases? It would be good to capture some metrics around this to understand the success rate of the image migration.

commented

The Go releases section is little unclear. Are you saying that the v0.12 release will have to be done BEFORE the repo is moved or after... because this is all just go mod magic anyway and we can do this transparently under github.com/ko-build/ko?

Good question. When the repo is moved, it will still have the Go module name github.com/google/ko because that's what's in the go.mod, and because GitHub will redirect the repo URL for us.

We can cut v0.12 any time, up to today even, with that notice that it will be moved in the future. I'd like to do this release first because I don't want the google/ko -> ko.build move to include any functional changes, and there's a lot of functional changes since v0.11 in March.

Also, the lack of redirects on image pull requests is disappointing but kind of makes sense. Do we have a feel for the volume of unique pull sources we see on daily bases? It would be good to capture some metrics around this to understand the success rate of the image migration.

The image doesn't get that much usage, honestly.

https://github.com/google/ko/pkgs/container/ko indicates it's been downloaded 3.7k times since it was added in December (#528), which is 15 pulls/day on average.

You can see per-version pull rates at https://github.com/google/ko/pkgs/container/ko/versions -- clicking back through the last few pages I don't see any that got more than ~150 pulls.

commented

Thanks, +1 on the version we cut in the new repo not having any functional changes. Keeps things clean.

On image pull metrics, I guess the daily doesn't mean much as some use cases may not be pulling as frequently or use caching which further reduces the cadence. Still, there isn't much we can do here so giving ample of notice (which we do) and assisting people with pointers to the new image when ready, is the best we can do.

commented

For folks watching this, this broke certain usages of setup-ko, which are fixed in ko-build/setup-ko#4

This only broke users who relied on the implicit default latest-release, and users who specified a version (including tip) should be unaffected.

You can update to use this commit:

- uses: imjasonh/setup-ko
+ uses: imjasonh/setup-ko@ace48d793556083a76f1e3e6068850c1f4a369aa

or just uses: imjasonh/setup-ko@v0.6

commented

I've enable public packages on the repo level which enabled us to make the ko package public. Let me know @imjasonh if you see any more issues with this

commented

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

commented

Just an update: most of the items remaining are waiting on the outcome of ko's proposal as a CNCF sandbox project, and making myself and any other potential non-Google contributors org owners so we can carry out the remaining items. When (if) CNCF accepts the project we'll also donate the ko.build domain, which I currently personally own, and as such don't feel comfortable making it a load-bearing part of ko's infrastructure until its bus factor is a little higher.

tl;dr: remaining items currently blocked on CNCF Sandbox decision. 🤞

commented

https://opensource.googleblog.com/2022/10/ko-applies-to-become-a-cncf-sandbox-project.html

=>

cncf/toc#945

=>

cncf/toc#945 (comment)

=>

https://sandbox.cncf.io/

I don't see a currently open Sandbox application anywhere, I think there may be a gap there?

commented

Thanks @BenTheElder that does indeed seem like a gap. 🙃

@mchmarny Did you open a Sandbox application through the sandbox repo after toc#945 was closed?

I'll start one now and link it here.

edit: cncf/sandbox#17

Thanks again Ben!

commented

Just an update: https://github.com/imjasonh/setup-ko has moved to the ko-build org.

The last two remaining items at this point are to move the terraform provider, and to update the importpath. I hope to move the terraform provider today, and the importpath possibly next week.