Using prior builds for improving encapsulation

[RishabhSaini]

Fixes: #4247
To do:

• Adding cmd option of taking prior builds
• Passing packing structure to ostree-rs-ext/pull/456
• Adding test case for encapsulation and encapsulation_derived

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[RishabhSaini]

We also need to tackle the case where we need to supply --write-frequency-info-to to compose tree and that same file should be referred in --frequencyinfo in container-encapsulate during the separate invocations of these commands in cosa build

What would be a better way to supply the metadata to container encapsulate?

[cgwalters]

We also need to tackle the case where we need to supply --write-frequency-info-to to compose tree and that same file should be referred in --frequencyinfo in container-encapsulate during the separate invocations of these commands in cosa build

I think we can stash this file in the temporary directory allocated in compose image right?

rpm-ostree/rust/src/compose.rs

Line 144 in f525121

let tempdir = Utf8Path::from_path(tempdir.path()).unwrap();

[cgwalters]

Just a few nits

[cgwalters]

Looks like this needs a rebase now?

[cgwalters]

This actually needed another rebase after #4422

I also reworked the two commits such that all the changes related to bumping ostree-ext were in the prior commit.

[cgwalters]

OK, I think this is good to land! There's clearly some followup we will want to do but I think we can iterate on that after merging.

[cgwalters]

Blah, I shouldn't have merged that dependabot clap rebase, it conflicted. Rebased this on that anyways though.

[cgwalters]

OK needed a small tweak for the usage test due to the clap change. Not sure what's going wrong though in the container failure, might just be the same timeout as other jobs though.

[RishabhSaini]

Not sure why the destructive tests are failing

[cgwalters]

Not sure yet either...as far as I can tell, we seem to be failing to reboot?

[cgwalters]

OK so I debugged this using

walters@toolbox /v/s/w/s/g/c/coreos-assembler (enable-ostree-composefs)> git diff
diff --git a/mantle/kola/harness.go b/mantle/kola/harness.go
index ac539638d..e39c028cc 100644
--- a/mantle/kola/harness.go
+++ b/mantle/kola/harness.go
@@ -1085,6 +1085,7 @@ Environment=KOLA_UNIT=%s
 Environment=KOLA_TEST=%s
 Environment=KOLA_TEST_EXE=%s
 Environment=%s=%s
+StandardOutput=journal+console
 ExecStart=%s
 `, unitName, testname, base, kolaExtBinDataEnv, destDataDir, remotepath)
        if targetMeta.InjectContainer {

(Should probably make this something like kola run --debug-ext-to-console or something)

Anyways the problem is the automatic upgrade trigger is failing:

[   26.058914] kola-runext-container-image[1189]: May 23 21:19:43 qemu0 rpm-ostree[1138]: Txn AutomaticUpdateTrigger on /org/projectatomic/rpmostree1/fedora_coreos failed: While checking against deployment timestamp: Upgrade target revision '630f678a16cf080256783b906540906da0b75763905f8d4bc15300fe0bb5af47' with timestamp 'Tue May 23 20:59:57 2023' is chronologically older than current revision '96a6844b758443cb4287a25e74bef511ddd7df00f264d01b4196ff19efb7d55e' with timestamp 'Tue May 23 21:18:46 2023'; use --allow-downgrade to permit

(So we don't reboot, hence hang)

And I think that is fallout from ostreedev/ostree-rs-ext@6c6f9a0
EDIT: No, it must be fallout from ostreedev/ostree-rs-ext@f450812

Which...perhaps arguably is actually a good thing. Hmm.

[cgwalters]

OK, pushed a change that should fix this.