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

ko needs an --osversion flag #534

Closed
imjasonh opened this issue Dec 13, 2021 · 0 comments · Fixed by #536
Closed

ko needs an --osversion flag #534

imjasonh opened this issue Dec 13, 2021 · 0 comments · Fixed by #536
Milestone

Comments

@imjasonh
Copy link
Member

Discovered while testing #533

The golang:1.17 base image provides platform-specific Linux and Windows images, and even a number of different Windows images for different Windows versions:

$ crane manifest golang:1.17 | jq '.manifests[].platform'                                                                                                                                                                                 
...
{
  "architecture": "amd64",
  "os": "windows",
  "os.version": "10.0.20348.350"
}
{
  "architecture": "amd64",
  "os": "windows",
  "os.version": "10.0.17763.2300"
}
{
  "architecture": "amd64",
  "os": "windows",
  "os.version": "10.0.14393.4770"
}

For GitHub Actions to work, ko needs to select the middle one, for os.version: 10.0.17763.2300 (or any 10.0.17763, probably). But --platform=amd64/windows will naively select the first one, and produce an image that doesn't run on GitHub Actions' windows-latest. --platform=all would work, it would simply build more images than it needs, including one for the correct 10.0.17763 image. Even if the correct image was listed first, there's no guarantee that golang won't change the order and break us, so we should be explicit about which one we match and build on.

This is similar in spirit to google/go-containerregistry#1173 which added an --osversion flag to crane to take the os.version into account when matching a platform. ko's support should work in much the same way.

@jonjohnsonjr

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 a pull request may close this issue.

1 participant