The release in sig-cloud-okd repo is hardcoded which is consumed by all the releases pipelines.
I guess it's not critical currently as 4.15 may not diverged too much from 4.14, but it might be in the future.
We can fix it with a sed 's/4.14/4.15/' alike command after the cosa-init execution as we do for the RPM artifacts
|
sed -i 's/rhel-9.*-server-ose.*/artifacts/' $(readlink -f src/config/manifest-$(params.variant).yaml) |
The second option is to define the whole repo and add it at the end of
src/config/c9s.repo as we do for artifacts
|
cat <<EOF >> src/config/c9s.repo |
|
|
|
[artifacts] |
|
name=OKD RPM artifacts |
|
baseurl=file:///workspace/coreos/rpms/ |
|
repo_gpgcheck=0 |
|
gpgcheck=0 |
|
enabled=1 |
|
|
|
EOF |
This option is better aligned with the layerd build effort
#46 as, IIUC, the
sig-cloud-okd repo definition in
src/config/c9s.repo will be removed at the end (to separate SCOS and OKD).
But we first need to tag the builds in the cloud9s-okd-4.15-release tag
I can do the tags, and even build the new NVRs but I'd need the exact version of what's in 4.15 release
The release in
sig-cloud-okdrepo is hardcoded which is consumed by all the releases pipelines.I guess it's not critical currently as 4.15 may not diverged too much from 4.14, but it might be in the future.
We can fix it with a
sed 's/4.14/4.15/'alike command after thecosa-initexecution as we do for the RPM artifactsokd-coreos-pipeline/base/tekton.dev/tasks/cosa-init.yaml
Line 61 in 487be68
The second option is to define the whole repo and add it at the end of
src/config/c9s.repoas we do for artifactsokd-coreos-pipeline/base/tekton.dev/tasks/cosa-init.yaml
Lines 62 to 71 in 487be68
This option is better aligned with the layerd build effort #46 as, IIUC, the
sig-cloud-okdrepo definition insrc/config/c9s.repowill be removed at the end (to separate SCOS and OKD).But we first need to tag the builds in the cloud9s-okd-4.15-release tag
I can do the tags, and even build the new NVRs but I'd need the exact version of what's in 4.15 release