Add JSON formatting check to the add-ign function

[skyblaster]

Fixes #187

[baude]

@skyblaster if you can fix the test failure, ill review and merge.

[skyblaster]

@baude I'm unfamiliar with these particular tests, and not sure why it's failing, so will have to defer to @ashley-cui

If I download libhvee-0.6.0 or later releases, and run .\winmake.ps1 localtest on my local machine, I see the exact same errors.
If I simply run .\winmake.ps1 binaries, the executables are built without any errors.

[skyblaster]

With a little debugging, I can say that the following URL needs to be updated as it results in a 404 which causes the win_test error:

libhvee/test/e2e/fedora_test.go

Line 18 in 24e21b4

fedoraBaseDirEndpoint = "https://kojipkgs.fedoraproject.org/compose/cloud/latest-Fedora-Cloud-39/compose"

Unfortunately it's not as simple as changing 39 to 40 or 41, as the new VHD images are compressed.

Example from 39: https://kojipkgs.fedoraproject.org/compose/metadata-archive/2024/Fedora-Cloud-39-20241126.0/images.json

                    {
                        "arch": "x86_64",
                        "bootable": false,
                        "checksums": {
                            "sha256": "b0ec83ff08499959ab9590cafc1d71645a48962ca10fbecf2aca2f6f3e0945ab"
                        },
                        "disc_count": 1,
                        "disc_number": 1,
                        "format": "vhd",
                        "implant_md5": null,
                        "mtime": 1732602402,
                        "path": "Cloud/x86_64/images/Fedora-Cloud-Base-Azure-39-20241126.0.x86_64.vhd",
                        "size": 1292184064,
                        "subvariant": "Cloud_Base",
                        "type": "vpc",
                        "volume_id": null
                    },

New compressed format: https://kojipkgs.fedoraproject.org/compose/cloud/latest-Fedora-Cloud-41/compose/metadata/images.json

                    {
                        "arch": "x86_64",
                        "bootable": false,
                        "checksums": {
                            "sha256": "c668dc15cddfae34649cb719c785bcbfdff858b10b2394fb6569bd676befa31a"
                        },
                        "disc_count": 1,
                        "disc_number": 1,
                        "format": "vhd.xz",
                        "implant_md5": null,
                        "mtime": 1734333904,
                        "path": "Cloud/x86_64/images/Fedora-Cloud-Base-Azure-41-20241216.0.x86_64.vhdfixed.xz",
                        "size": 527791932,
                        "subvariant": "Cloud_Base",
                        "type": "vhd-compressed",
                        "volume_id": null
                    },

[skyblaster]

@baude I took a stab at fixing the e2e testing and it now passes.
The path to 41 seems to have disappeared, so I had to use 40.

I'm not sure why it appears to copy the decompressed image twice, so please have a look https://cirrus-ci.com/task/6376975813574656

Sorry for the lack of a sign-off. Please let me know if I should rebase, or resubmit the PR.

[baude]

@skyblaster thanks! I was working on this before PTO and same thing as you ... only difference is I added a command line tool to the test image to unxz because the golang library is known to be very slow for decompression. Lets go ahead and merge this and I can switch over to the command line once I'm caught back up

[baude]

mind changing to 41?

[Luap99]

Just noticed this as well in my image update Pr and tried to do a quick fix #197

Anyway it is complicated as there is no f41 on the server: i.e. 404 https://kojipkgs.fedoraproject.org/compose/cloud/latest-Fedora-Cloud-41/

I asked in the Fedora cloud matrix to see if this is a bug or not on their end. So Sticking to f40 seems to be the right call for now

[Luap99]

https://pagure.io/releng/issue/12521

[baude]

works for me

[baude]

just return err

[baude]

return vhdPath, err wdyt ?

[Luap99]

@skyblaster Can you sign-off your commits, see https://github.com/containers/common/blob/main/CONTRIBUTING.md#sign-your-prs

We cannot accept contributions with unclear copyright status.

We can fixup the minor nits and migrate to the cli tool at a later point. In the interest of working CI I think this is great to merge

[skyblaster]

My apologies for the delay and for not creating a branch of my original fork, so as to keep the two commits separate.
I was attempting to work on Brent's suggested changes, but ran out of steam as I'll admit I'm not much of a programmer.
If you're okay with accepting it as is, I'm happy to see it merged.

Cheers!

[Luap99]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, skyblaster

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Luap99]

Thanks for the work @skyblaster, no need to apologize

[baude]

@skyblaster thank you very much for your contribution!

/lgtm