i/statemachine: fix manifest generation for classic image by fhost · Pull Request #288 · canonical/ubuntu-image

fhost · 2026-02-13T22:36:38Z

Make the classic image manifest follow the same format as the one from livecd-rootfs.
Changes:

Use tab instead of space in the manifest
Add snaps to the manifest

codecov · 2026-02-16T14:46:33Z

Codecov Report

❌ Patch coverage is 78.94737% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.40%. Comparing base (5ae01fe) to head (7d550e6).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/statemachine/helper.go	78.37%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #288      +/-   ##
==========================================
- Coverage   93.52%   93.40%   -0.13%     
==========================================
  Files          19       19              
  Lines        3539     3563      +24     
==========================================
+ Hits         3310     3328      +18     
- Misses        150      153       +3     
- Partials       79       82       +3

Flag	Coverage Δ
unittests	`93.40% <78.94%> (-0.13%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

fhost · 2026-02-16T14:53:44Z

(I'll do the coverage if you do accept the modification)

mwhudson · 2026-02-18T00:56:26Z

 }

+// GenerateClassicManifest generate the classic manifest file for the given rootfs
+func GenerateClassicManifest(rootfs string, outputPath string, debug bool) error {


does this need to be exported?

Yes, it is used in classic_state.go.

that's in the same package though? my Go is a bit rusty but I'm not that out of it yet!

My Go is a bit too new, so I did not know it works like this :)

mwhudson

i do want you to unexport GenerateClassicManifest please

mwhudson · 2026-02-19T03:37:46Z

 }

+// GenerateClassicManifest generate the classic manifest file for the given rootfs
+func GenerateClassicManifest(rootfs string, outputPath string, debug bool) error {


that's in the same package though? my Go is a bit rusty but I'm not that out of it yet!

Make the classic image manifest follow the same format as the one from livecd-rootfs. Changes: * Use tab instead of space in the manifest * Add snaps to the manifest

upils

The manifest currently produced is very likely consumed by some tools by some people. So this change would be a breaking change due to the 2 changes you mention in the description. I would like to avoid that if possible.

I am more inclined to post-process the output than change it. We have unfortunately no way to express the format version so this will be a surprising change for users.

I assume the space->tab issue could be solved with a call to sed. Is that so or is that more complex?
Also, in the README, it is clearly stated that the manifest lists packages, the current proposition would change this definition.

I agree the snaps list is currently missing and that would be nice to extract it. What do you think of generating another separate "snaps.manifest" file, listing snaps (and maybe using the tab separator?)? A bit a thinking is needed to define how that would be expressed in the image definition file but we can discuss it.
With that, the post-process would also be trivial before calling sbom-generate.

upils · 2026-02-25T11:09:57Z

 	return nil
 }

+// generateClassicManifest generate the classic manifest file for the given rootfs


Suggested change

// generateClassicManifest generate the classic manifest file for the given rootfs

// generateClassicManifest generates the classic manifest file for the given rootfs

fhost · 2026-02-25T12:27:22Z

The manifest currently produced is very likely consumed by some tools by some people. So this change would be a breaking change due to the 2 changes you mention in the description. I would like to avoid that if possible.

It is what I'm afraid of.

I am more inclined to post-process the output than change it. We have unfortunately no way to express the format version so this will be a surprising change for users.

I assume the space->tab issue could be solved with a call to sed. Is that so or is that more complex? Also, in the README, it is clearly stated that the manifest lists packages, the current proposition would change this definition.

I guess the tab/space issue could be also solved on sbom side (i.e. accepting both). But we do need the snap list.

I agree the snaps list is currently missing and that would be nice to extract it. What do you think of generating another separate "snaps.manifest" file, listing snaps (and maybe using the tab separator?)? A bit a thinking is needed to define how that would be expressed in the image definition file but we can discuss it. With that, the post-process would also be trivial before calling sbom-generate.

Could we add another artifact entry and generates that manifest (tab + snap) if specified? Not sure about a name tho, as it is also a manifest ^^´

artifacts:
  img:
    - name: ubuntu-24.04-preinstalled-server-arm64+dragonwing.img
  manifest:
    name: ubuntu-24.04-preinstalled-server-arm64+dragonwing.manifest
  full-manifest:
    name: buntu-24.04-preinstalled-server-arm64+dragonwing-with-snap-and-tabs.manifest

upils · 2026-02-25T14:39:46Z

Could we add another artifact entry and generates that manifest (tab + snap) if specified?

This is another possibility but as you pointed out it might be tricky to find a good name (because the concept might be hard to express, which might indicate something is fishy). Side note: this is unlikely, but if we ever add another kind of object, the "full-manifest" name might be misleading or might see its definition change.

Another approach would be to add a new "manifest-v2" (name TBD here too) that would accept a list of "kinds" (package,snap, etc.). So users could express precisely what they want in the manifest. Drawbacks:

This might be giving too much freedom to users
There is no good default

fhost · 2026-02-26T08:44:21Z

This is another possibility but as you pointed out it might be tricky to find a good name (because the concept might be hard to express, which might indicate something is fishy). Side note: this is unlikely, but if we ever add another kind of object, the "full-manifest" name might be misleading or might see its definition change.

The fishy part is that we have different tools that output different manfiests and we're trying to align them ^^´
And yes, "full-manifest" is not a good name. Maybe the "manifest-v2" is a good name. It's just another "format" for the manifest. And you're using "manifest" to get the legacy manifest or "manifest-v2" to get the "new" one.

Another approach would be to add a new "manifest-v2" (name TBD here too) that would accept a list of "kinds" (package,snap, etc.). So users could express precisely what they want in the manifest. Drawbacks:
* This might be giving too much freedom to users

* There is no good default

Yeah, the point is to have the same manifest format everywhere, so I don't think it is a good idea to give user customization.

fhost requested review from mwhudson and upils February 13, 2026 22:36

fhost force-pushed the fhost/manifest branch 3 times, most recently from 2031a11 to b3228f7 Compare February 16, 2026 14:43

mwhudson reviewed Feb 18, 2026

View reviewed changes

fhost requested a review from mwhudson February 18, 2026 09:39

mwhudson requested changes Feb 19, 2026

View reviewed changes

i/statemachine: fix manifest generation for classic image

7d550e6

Make the classic image manifest follow the same format as the one from livecd-rootfs. Changes: * Use tab instead of space in the manifest * Add snaps to the manifest

fhost force-pushed the fhost/manifest branch from b3228f7 to 7d550e6 Compare February 19, 2026 09:39

fhost requested a review from mwhudson February 19, 2026 09:39

upils requested changes Feb 25, 2026

View reviewed changes

	// generateClassicManifest generate the classic manifest file for the given rootfs
	// generateClassicManifest generates the classic manifest file for the given rootfs

Conversation

fhost commented Feb 13, 2026

Uh oh!

codecov Bot commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

fhost commented Feb 16, 2026

Uh oh!

mwhudson Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

fhost Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

mwhudson Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

fhost Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

fhost Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mwhudson left a comment

Choose a reason for hiding this comment

Uh oh!

mwhudson Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

upils left a comment

Choose a reason for hiding this comment

Uh oh!

upils Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

fhost commented Feb 25, 2026

Uh oh!

upils commented Feb 25, 2026

Uh oh!

fhost commented Feb 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov Bot commented Feb 16, 2026 •

edited

Loading