cmd-build: Conditionally change the packing structure of container-image

[RishabhSaini]

Fixes #3506
Enable feature detection
When the previous build exists, use its packing structure otherwise container-encapsulate generates a new one

[cgwalters]

One thing that'd probably help here is for us to have a CI flow that actually uses prior builds and better simulates a pipeline run. Hmm...that may not be hard actually.

[RishabhSaini]

One thing that'd probably help here is for us to have a CI flow that actually uses prior builds and better simulates a pipeline run. Hmm...that may not be hard actually.

As I can see, there exists a workflow in coreos-assembler/ci/prow-rhcos.sh which executes openshift/os/ci/prow-entrypoint.sh rhcos-cosa-prow-pr-ci. This does a simple cosa init, fetch, build, test.

Thus to create two new workflow where a 1) previous local build and 2) buildfetch is used to build a new image, I would need to add lines here for new endpoints like this.

1. Simulating the case of an existing previous local build
   I would need to create a new function cosa_previous_build() in here which would:

// Get and build an older rhcos to have a previous local build in builds directory
cosa buildfetch --url={old_rhcos}
cosa build 

// Get and build a newer rhcos so it uses the previous local build
cosa fetch
cosa build

2. Simulating the case of a buildfetch of an older build
   I would need to create a new function cosa_buildfetch() in here which would:

// Get and build an older rhcos to have a previous local build in builds directory
cosa buildfetch --url={old_rhcos}

// Get and build a newer rhcos so it uses the buildfetch metadata
cosa fetch
cosa build

Is this the correct implementation?

[cgwalters]

There's an argument we should just change the default for Prow CI to use buildfetch because that's the production path.

[cgwalters]

/override ci/prow/rhcos
I think the new code is good and we can address the tech debt of "CI flow for cosa with a previous build" as a followup later

[openshift-ci]

@cgwalters: Overrode contexts on behalf of cgwalters: ci/prow/rhcos

In response to this:

/override ci/prow/rhcos
I think the new code is good and we can address the tech debt of "CI flow for cosa with a previous build" as a followup later

Instructions 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.

[dustymabe]

This appears to have broken builds: coreos/fedora-coreos-streams#735 (comment)

I reverted the tag update in quay and a revert PR was opened at #3528

[cgwalters]

Argh, sorry...again!

I suspect what we're running into here is the case where the previous build doesn't have the manifest; we need to check if it exists before adding it to --previous-build-manifest.

[dustymabe]

Argh, sorry...again!

😆

I suspect what we're running into here is the case where the previous build doesn't have the manifest; we need to check if it exists before adding it to --previous-build-manifest.

No worries. I was going to say you could just test this in the pipeline by running a debug pod job (because you can specify the COSA image when you start the job) but that job is specifically for multi-arch right now so you'd need to have pushed a manifest listed image. We should modify that job to support our x86_64 workflow too.

[RishabhSaini]

you could just test this in the pipeline by running a debug pod job

How can I trigger this job? Is there a manual or a documentation I could refer to?

[aaradhak]

@RishabhSaini :

1. You may access the debug pod job and start a build with parameters by provisioning the CoreOS stream, arch, cosa_img to override (if needed) and timeout value. The timeout is set to be 8 hrs by default.

2. After the build is triggered, this job spins up and starts a remote session on the builder of your chosen architecture and sets up the cosa environment and enter into a sleep state within a minute.

3. You would be able to access the pod that was created at OCP. The pod that was created would carry your 'username' with prefix "debug-pod".

4. You can access the terminal and enter "tmux attach" which would open the two panes. The top pane would be a ssh shell on the remote builder and the bottom pane would be a cosa shell in a remote session.