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

Allow configuration of `platform` #36

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@cirocosta
Copy link
Member

commented Apr 27, 2019

Hey,

I was giving a try at running Concourse on ARMv7 (worked!), and one of the modifications needed was making registry-image gather container images built for such a platform.

Without the explicit use of platform, the underlying library ends up
using its own default (amd64). This is a problem for those running the
resource in other architectures.

To achieve that:

  • bumps go-containerregistry to make
  • sets Platform to the {GOOS, GOARCH} by default, allowing the
    possibility of having that set through a platform field in the
    resource config.

Example:

resources:
- type: registry-image
  name: busybox-arm
  source:
    repository: busybox
    platform: {os: linux, architecture: arm}

The biggest uncertainty that I have regarding this at the moment is the default values - should we leave them as the values chosen for GOOS and GOARCH at build time, or make it by default a specific setting (like, linux amd64?)

Also, regarding testing, should we publish an image that is arm-based to DockerHub so we can ensure that in the tests we gather the expected digest?

Wdyt?

Thanks!

Allow configuration of `platform`
Without the explcit use of `platform`, the underlying library ends up
using its own default (amd64). This is a problem for those running the
resource in other architectures.

To achieve that:

- bumps `go-containerregistry` to make
- sets `Platform` to the `{GOOS, GOARCH}` by default, allowing the
  possibility of having that set through a `platform` field in the
  resource config.

Example:

```yaml
resources:
- type: registry-image
  name: busybox-arm
  source:
    repository: busybox
    platform: {os: linux, architecture: arm}
```

Signed-off-by: Ciro S. Costa <cscosta@pivotal.io>

ahuah

Signed-off-by: Ciro S. Costa <cscosta@pivotal.io>
@vito

This comment has been minimized.

Copy link
Member

commented May 13, 2019

Defaulting based on GOOS/GOARCH sounds sensible. So we would build + docker push + release a linux-arm variant of this resource, and anyone using it would have it default to the appropriate platform. As long as it's overrideable, it seems less arbitrary than defaulting to linux-amd64 everywhere.

The only risk would be whether folks would find this surprising, e.g. if they're fetching the image but not intending to actually run it on the same platform. But I think the trade-off in brevity when using the resource for the "common case" (image_resource:/resource_types:) on other platforms makes it worth the risk.

@vito

This comment has been minimized.

Copy link
Member

commented May 13, 2019

Also, regarding testing, should we publish an image that is arm-based to DockerHub so we can ensure that in the tests we gather the expected digest?

Hmm I guess so. This would be our first time supporting other platforms in a base resource type, but if we're gonna start somewhere this resource makes the most sense. Would this complicate the test setup?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.