refactors the prow build scripts#781
Conversation
|
/assign cgwalters |
Hmm yes. I think we're potentially losing all labels (metadata) with the magic step to import the ociarchive? But are you actually fixing that in this PR? If so I don't understand how? That said |
openshift-ci
Bot
added
the
approved
That's not what this fixes. This separates placing the OCI archive into a static path from the cosa-build process since that is only required by the import process and breaks the Kola tests. I don't think we're losing the labels, but I'll do a check on my next CI run to confirm / deny that. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, cheesesashimi The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Just an update: We're not losing the labels. If anything, we're gaining labels from the OpenShift Image Build (which are empty here because this is a rehearsal build or from an inline Dockerfile; not sure which). Here are the labels from an imported image from a previous CI run: {
"coreos-assembler.image-config-checksum": "a63a225142788970b32bb6571c3b120811785ac63152b900e588df3db9e0f997",
"coreos-assembler.image-input-checksum": "78599191ea1a0824158910c172bbbd5229e24b3e757bd47788787c160243bb9a",
"io.buildah.version": "1.22.4",
"io.openshift.build.commit.author": "",
"io.openshift.build.commit.date": "",
"io.openshift.build.commit.id": "",
"io.openshift.build.commit.message": "",
"io.openshift.build.commit.ref": "",
"io.openshift.build.name": "",
"io.openshift.build.namespace": "",
"io.openshift.build.source-context-dir": "",
"io.openshift.build.source-location": "",
"org.opencontainers.image.revision": "v0.0.2-574-g196356217e1b2ca4e482268b7d4e97d9474ba38b",
"org.opencontainers.image.source": "/tmp/cosa/src/config",
"ostree.bootable": "true",
"ostree.commit": "e930a0b6d432e48988be0dcca323af71ffec5cf0fddeb13c7f0d8b53c9d7cedc",
"ostree.diffid": "sha256:e1fc41840b113e551fbaf75bd87accbbff2460c4c84b7a35635a5bcdb6c9cad7",
"ostree.linux": "4.18.0-369.el8.x86_64",
"rpmostree.inputhash": "7b81ae96332ece9fb19aefbd1d9761b0c8ead18d8bea7f07299e30ad2ce8fa9c",
"vcs-ref": "",
"vcs-type": "",
"vcs-url": "",
"version": "411.86.202204191810-0"
} |
|
@cheesesashimi: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
The `validate` job started to fail with:
```
fatal: unsafe repository ('/go/src/github.com/openshift/os' is owned by someone else)
To add an exception for this directory, call:
git config --global --add safe.directory /go/src/github.com/openshift/os
```
Applying this suggestion as part of the `ci/validate.sh` script
(see openshift/os#802) fails with the error:
```
+ git config --global --add safe.directory /go/src/github.com/openshift/os
error: could not lock config file //.gitconfig: Permission denied
```
I suspect this is related to how the random user ID is configured in
OCP pods, similar to what is described in openshift/os#781, so I tried
using the `ci/set-openshift-user.sh` script as part of the `validate`
job.
Through trial and error, I found that using the `fcos-buildroot`
container based on F36 would not work with this change and had to
switch to using the `cosa:latest` container. Going further down the
rabbit hole, I found that I didn't need to use the
`ci/set-openshift-user.sh` script at all and just the `cosa:latest`
container was enough to get the `validate` job to pass. I don't claim
to fully understand why this is the case, but it does effectively
unblock the `validate` job.
3 participants
After a bit of experimenting, it was discovered that:
builderuser can be looked up by the random OpenShift user ID as well as to ensure that it has the necessary permissions to read and write files within the COSA_DIR directory.