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

libpod/image: Use ParseNormalizedNamed in RepoDigests #2106

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
7 participants
@wking
Copy link
Contributor

commented Jan 9, 2019

Avoid generating quay.io/openshift-release-dev/ocp-release@sha256@sha256:239... and similar when the image name is already digest-based. It's not clear exactly how we get into this state, but as shown by the unit tests, the new code handles this case correctly (while the previous code does not).

Fixes #2086

@openshift-ci-robot openshift-ci-robot requested review from giuseppe and vrothberg Jan 9, 2019

@wking wking force-pushed the wking:fix-repo-digests-name-parsing branch from c675435 to 397ba9d Jan 9, 2019

{
name: "digest",
names: []string{"docker.io/library/busybox@sha256:7173b809ca12ec5dee4506cd86be934c4596dd234ee82c0662eac04a8c2c71dc"},
expected: []string{"docker.io/library/busybox@sha256:7173b809ca12ec5dee4506cd86be934c4596dd234ee82c0662eac04a8c2c71dc"},

This comment has been minimized.

Copy link
@wking

wking Jan 9, 2019

Author Contributor

This test fails with the doubled @sha256 unless we also include the ParseNormalizedNamed change this commit makes to RepoDigests().

@@ -41,13 +41,18 @@ func (i *LibpodAPI) ListImages(call iopodman.VarlinkCall) error {
for _, image := range images {
labels, _ := image.Labels(getContext())
containers, _ := image.Containers()
repoDigests, err := image.RepoDigests()
if err != nil {
return err

This comment has been minimized.

Copy link
@wking

wking Jan 9, 2019

Author Contributor

I dunno why everyone else is ignoring errors here, but it's been that way since 39a7a77 (#669). @baude, do you remember your motivation?

This comment has been minimized.

Copy link
@vrothberg

vrothberg Jan 9, 2019

Member

image.Labels(...) seems to ignore errors as well.

This comment has been minimized.

Copy link
@wking

wking Jan 9, 2019

Author Contributor

image.Labels(...) seems to ignore errors as well.

Yeah, I left the existing error-ignores alone, since I don't understand their motivation. I'm happy to make these all consistent though (one way or the other) if someone can explain the motivation.

This comment has been minimized.

Copy link
@mheon

mheon Jan 9, 2019

Collaborator

It looks like we don't want to fatally fail when trying to get some information on an image, but it's not commented at all so I'm not sure. @baude this intentional?

@vrothberg

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

/approve

@openshift-ci-robot

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vrothberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rhatdan

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

{
name: "tagged",
names: []string{"docker.io/library/busybox:latest"},
expected: []string{"docker.io/library/busybox@sha256:7173b809ca12ec5dee4506cd86be934c4596dd234ee82c0662eac04a8c2c71dc"},

This comment has been minimized.

Copy link
@mheon

mheon Jan 9, 2019

Collaborator

How often does Busybox update (such that this would no longer pull the same image)?

Can we throw a comment on here that this needs updating when busybox bumps its image version?

This comment has been minimized.

Copy link
@wking

wking Jan 9, 2019

Author Contributor

How often does Busybox update...

This digest is hard-coded in the test itself; it is completely decoupled from any real-world BusyBox image. So no need to bump anything.

This comment has been minimized.

Copy link
@mheon

mheon Jan 9, 2019

Collaborator

Oh, sorry, I meant the line above - busybox:latest

This comment has been minimized.

Copy link
@wking

wking Jan 9, 2019

Author Contributor

Oh, sorry, I meant the line above - busybox:latest

Still just a string I'm hard-coding for these unit tests with no relation to real-world images. The new unit tests should just be exercising vendored string-manipulation code; they aren't hitting the network or anything.

This comment has been minimized.

Copy link
@mheon

mheon Jan 9, 2019

Collaborator

Alright, should be fine then, thanks

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

Few questions but code LGTM.

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

Tests are failing - looks like there's a :latest tag in there?

@wking

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

Tests are failing - looks like there's a :latest tag in there?

Do you know what's going in there. The unit tests pass for me locally, and we vendor the parser, so I dunno how CI is failing.

@rhatdan

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

Will attempt to rerun them to see if it is a flake.

@wking

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

The unit tests pass for me locally...

Actually, I must have changed something and forgotten to run them again, since now I can reproduce locally (thank you, CI ;). Obviously reference.WithDigest is not doing what I think it should be doing, since it preserves the tag which is no longer needed once you have a digest. @mtrmac, what's the proper invocation to attach a digest to a name, stripping the tag from tagged names?

@mtrmac

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

Obviously reference.WithDigest is not doing what I think it should be doing, since it preserves the tag which is no longer needed once you have a digest. @mtrmac, what's the proper invocation to attach a digest to a name, stripping the tag from tagged names?

reference.WithDigest(reference.TrimNamed(input), digest)

should work.

for _, name := range i.Names() {
repoDigests = append(repoDigests, strings.SplitN(name, ":", 2)[0]+"@"+i.Digest().String())
named, err := reference.ParseNormalizedNamed(name)
if err != nil {

This comment has been minimized.

Copy link
@mtrmac

mtrmac Jan 9, 2019

Collaborator

FWIW c/image/storage silently ignores errors (= .Names entries not in the c/image/docker/reference format).

Names are not documented to be in any particular format, so hard failures here may not be appropriate — OTOH maybe we should tighten the definition of Names instead. I don’t know.

This comment has been minimized.

Copy link
@wking

wking Jan 9, 2019

Author Contributor

Names are not documented to be in any particular format, so hard failures here may not be appropriate...

I don't have an opinion on what ParseNormaliedNamed wants to consider an error, but if it returns an error, I think we should be passing it back up the chain. I certainly don't want different opinions on what names are considered valid living at different places in the stack.

This comment has been minimized.

Copy link
@mtrmac

mtrmac Jan 9, 2019

Collaborator

I’m saying that the existing opinion/practice is that non-ParseNormalizedNamed names are 1) allowed and 2) silently ignored, so if you ”don’t want different opinions” (which I agree with) the right thing to do is to silently ignore such names as well.

I do support tightening the definition, but if that should happen, it needs be a separate PR set across c/storage (documenting the field as such)+c/image+libpod (using it) and maybe others.

@wking wking force-pushed the wking:fix-repo-digests-name-parsing branch from 397ba9d to f539fd2 Jan 9, 2019

@wking

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

I've pushed 397ba9d -> f539fd2 adding TrimedName, which should green up CI (it works for me locally).

@rhatdan

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

@wking Still broken :^(

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

@wking I think the issue with CI was introduced by the most recent merge (another user of RepoDigests appeared and needs to be changed to use the error return)

libpod/image: Use ParseNormalizedNamed in RepoDigests
Avoid generating
quay.io/openshift-release-dev/ocp-release@sha256@sha256:239... and
similar when the image name is already digest-based [1].  It's not
clear exactly how we get into this state, but as shown by the unit
tests, the new code handles this case correctly (while the previous
code does not).

[1]: #2086

Signed-off-by: W. Trevor King <wking@tremily.us>

@wking wking force-pushed the wking:fix-repo-digests-name-parsing branch from f539fd2 to a780521 Jan 9, 2019

@wking

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

Rebased around #2040 with f539fd2 -> a780521.

@wking

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2019

All green :).

@mheon

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

Code LGTM

@rhatdan

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

@rh-atomic-bot

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

📌 Commit a780521 has been approved by rhatdan

@rh-atomic-bot

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

⌛️ Testing commit a780521 with merge 0f6535c...

@rh-atomic-bot

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

☀️ Test successful - status-papr
Approved by: rhatdan
Pushing 0f6535c to master...

wking added a commit to wking/openshift-installer that referenced this pull request Jan 27, 2019

hack/build: Pin to RHCOS 47.280 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.2

RHCOS 47.280 brings in, among other things, [1], which fixes a bug we
see occasionally on the bootstrap machine.

Clayton pushed 4.0.0-0.nightly-2019-01-25-205123 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.2.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.280/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

wking added a commit to wking/openshift-installer that referenced this pull request Jan 27, 2019

hack/build: Pin to RHCOS 47.280 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.2

RHCOS 47.280 brings in, among other things, [1], which fixes a bug we
see occasionally on the bootstrap machine.

Clayton pushed 4.0.0-0.nightly-2019-01-25-205123 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.2.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.280/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

@wking wking deleted the wking:fix-repo-digests-name-parsing branch Jan 31, 2019

wking added a commit to wking/libpod that referenced this pull request Jan 31, 2019

libpod/image: Use RepoDigests() in Inspect()
To get the more-robust handling from 0f6535c (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, containers#2106) here too.

wking added a commit to wking/libpod that referenced this pull request Jan 31, 2019

libpod/image: Use RepoDigests() in Inspect()
To get the more-robust handling from 0f6535c (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, containers#2106) here too.

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/libpod that referenced this pull request Jan 31, 2019

libpod/image: Use RepoDigests() in Inspect()
To get the more-robust handling from 0f6535c (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, containers#2106) here too.

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/openshift-installer that referenced this pull request Feb 5, 2019

hack/build: Pin to RHCOS 47.297 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.3

The bump from RHCOS 47.280 to 47.297 brings in, among other things,
v0.12 kubelets.

Clayton pushed 4.0.0-0.nightly-2019-01-30-145955 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.3.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.297/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

wking added a commit to wking/openshift-installer that referenced this pull request Feb 5, 2019

hack/build: Pin to RHCOS 47.297 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.3

The bump from RHCOS 47.280 to 47.297 brings in, among other things,
v0.12 kubelets.

Clayton pushed 4.0.0-0.nightly-2019-01-30-145955 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.3.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.297/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

wking added a commit to wking/openshift-installer that referenced this pull request Feb 5, 2019

hack/build: Pin to RHCOS 47.297 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.3

The bump from RHCOS 47.280 to 47.297 brings in, among other things,
v0.12 kubelets.

Clayton pushed 4.0.0-0.nightly-2019-01-30-145955 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.3.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.297/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

wking added a commit to wking/openshift-installer that referenced this pull request Feb 5, 2019

hack/build: Pin to RHCOS 47.297 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.3

The bump from RHCOS 47.280 to 47.297 brings in, among other things,
v0.12 kubelets.

Clayton pushed 4.0.0-0.nightly-2019-01-30-145955 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.3.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.297/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

mheon added a commit to mheon/libpod that referenced this pull request Feb 8, 2019

libpod/image: Use RepoDigests() in Inspect()
To get the more-robust handling from 0f6535c (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, containers#2106) here too.

Signed-off-by: W. Trevor King <wking@tremily.us>

mheon added a commit to mheon/libpod that referenced this pull request Feb 8, 2019

libpod/image: Use RepoDigests() in Inspect()
To get the more-robust handling from 0f6535c (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, containers#2106) here too.

Signed-off-by: W. Trevor King <wking@tremily.us>

wking added a commit to wking/openshift-installer that referenced this pull request Feb 19, 2019

hack/build: Pin to RHCOS 47.318 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.4

The bump from RHCOS 47.297 to 47.318 brings in, among other things,
Podman 1.0.1.

Clayton pushed 4.0.0-0.nightly-2019-02-17-024922 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.4.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.318/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

wking added a commit to wking/openshift-installer that referenced this pull request Feb 27, 2019

hack/build: Pin to RHCOS 47.330 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.5

Clayton pushed 4.0.0-0.nightly-2019-02-26-125216 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.5.  Extracting the
associated RHCOS build:

  $ oc adm release info --pullspecs quay.io/openshift-release-dev/ocp-release:4.0.0-0.5 | grep machine-os-content
    machine-os-content                            registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-02-26-125216@sha256:1262533e31a427917f94babeef2774c98373409897863ae742ff04120f32f79b
  $ oc image info registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-02-26-125216@sha256:1262533e31a427917f94babeef2774c98373409897863ae742ff04120f32f79b | grep version
              version=47.330

The bump from RHCOS 47.297 to 47.330 brings in, among other things,
Podman 1.0.1.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.330/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106

wking added a commit to wking/openshift-installer that referenced this pull request Feb 27, 2019

hack/build: Pin to RHCOS 47.330 and quay.io/openshift-release-dev/ocp…
…-release:4.0.0-0.5

Clayton pushed 4.0.0-0.nightly-2019-02-26-125216 to
quay.io/openshift-release-dev/ocp-release:4.0.0-0.5.  Extracting the
associated RHCOS build:

  $ oc adm release info --pullspecs quay.io/openshift-release-dev/ocp-release:4.0.0-0.5 | grep machine-os-content
    machine-os-content                            registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-02-26-125216@sha256:1262533e31a427917f94babeef2774c98373409897863ae742ff04120f32f79b
  $ oc image info registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-02-26-125216@sha256:1262533e31a427917f94babeef2774c98373409897863ae742ff04120f32f79b | grep version
              version=47.330

The bump from RHCOS 47.297 to 47.330 brings in, among other things,
Podman 1.0.1.

Renaming OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE gets us CI testing
of the pinned release despite openshift/release@60007df (Use
RELEASE_IMAGE_LATEST for CVO payload, 2018-10-03,
openshift/release#1793).

Also comment out regions which this particular RHCOS build wasn't
pushed to, leaving only:

  $ curl -s https://releases-rhcos.svc.ci.openshift.org/storage/releases/maipo/47.330/meta.json | jq -r '.amis[] | .name'
  ap-northeast-1
  ap-northeast-2
  ap-south-1
  ap-southeast-1
  ap-southeast-2
  ca-central-1
  eu-central-1
  eu-west-1
  eu-west-2
  eu-west-3
  sa-east-1
  us-east-1
  us-east-2
  us-west-1
  us-west-2

I'd initially expected to export the pinning environment variables in
release.sh, but I've put them in build.sh here because our continuous
integration tests use build.sh directly and don't go through
release.sh.

[1]: containers/libpod#2106
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.