You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are we sure we want to add a new ops file when no one can use it? Perhaps we'd be better off just having a fan-out in the cf-deployment pipeline that uses the latest FIPs, and also trigger it when a new FIPs comes in. I guess it's a bit hacky either way.
That's because the "os" or "stack" is the same as for the regular stemcell. This can indeed be confusing. The only purpose of this file is to manage the version of the FIPS stemcell. The idea is to design this similar to the operations/windows2019-cell.yml ops file. A new incoming stemcell version is written in the ops file and committed. That will trigger the cf-deployment pipeline. If we used the bosh-io-stemcell resource as trigger, we wouldn't have the version defined in cf-deployment, unless we used a sophisticated job like https://concourse.wg-ard.ci.cloudfoundry.org/teams/main/pipelines/update-releases/jobs/update-stemcell-minor.
We can discuss how to proceed in this week's ARD WG meeting.
We want to integrate the FIPS stemcell validation into the cf-deployment pipeline, instead of running a separate pipeline. The approach should be similar to the "update-windows2019-stemcell" process:
https://concourse.wg-ard.ci.cloudfoundry.org/teams/main/pipelines/update-releases?group=update-windows-stemcells-and-releases
Tasks:
update-stemcell-ops
task in "runtime-ci" project: Refactor update-stemcell-ops task runtime-ci#358The text was updated successfully, but these errors were encountered: