Google repo manifest support

[miketsukerman]

Did someone already considered adding support for repo manifests? Something like

header:
  version: 20

manifests:
  nxp:
    url: "https://github.com/nxp-imx/imx-manifest.git"
    branch: "imx-linux-walnascar"
    manifest: "imx-6.12.34-2.1.0.xml"

repos:
  meta-rauc:
    url: "https://github.com/rauc/meta-rauc.git"
    branch: "walnascar"
    path: "layers/meta-rauc"
    layers:
      .:

[fmoessbauer]

Hi, I was working on a manifest to kas converter based on the work in https://groups.google.com/g/kas-devel/c/Dk2AKNx0PQA/m/uV_mU6w_BAAJ . The tool itself was already in a pretty good shape, but then other topics kept me busy. I'll send out a rebase onto current next within the next week. If you have time to continue my work (at least by testing it), that would be appreciated.

[miketsukerman]

@fmoessbauer cool, I would definitely try it out.

[jan-kiszka]

Would an offline conversion step via that tool be fine, or do we actually need referencing of repo xml inside a kas config, thus live parsing when starting kas?

[miketsukerman]

Would an offline conversion step via that tool be fine, or do we actually need referencing of repo xml inside a kas config, thus live parsing when starting kas?

@jan-kiszka Thank you for a good question. Coversion from repo XML format to YAML is a good option in case when someone wants to migrate his yocto manifest from repo to KAS. Maybe even round trip would be cool to support. XML -> YAML -> XML.

But, generally speaking, both options should be available. It depends on the case. What if I need to extend a 3rd party repo manifest file.

[jan-kiszka]

I'm specifically asking as we here have not yet run into the need to repeatedly convert repo manifests. So it would be an extra invest to make that happen. What would help, of course, are people willing to actively work on the full feature set 😉 .

[miketsukerman]

I'm specifically asking as we here have not yet run into the need to repeatedly convert repo manifests. So it would be an extra invest to make that happen. What would help, of course, are people willing to actively work on the full feature set 😉 .

@jan-kiszka understood. I have such a need (and potentially many other people might have as well) and will try to work on this feature. I was asking here to find out are there any blockers on adding such a feature, because it seems to be quite straightforward to do and super beneficial.

[fmoessbauer]

Hi @miketsukerman ,

here is a dump of my work-in-progress on the merger. I just rebased it onto kas:next (5.0), but otherwise kept in in the state it was a year ago. https://github.com/fmoessbauer/kas/tree/fm/convert

In short, it already includes the following:

• a kas schema addition to track linkfiles
• a script to convert the manifest to kas: repoManifest2kasYml.py
• a very rough script to convert the bitbake variables after running the setup script (uses the oelint parser)

With that, the workflow would be:

repoManifest2kasYml.py default.xml > kas.yml
kas checkout kas.yml
# run setup script
repoManifestStep2.py kas.yml <builddir> > kas-final.yml
kas build kas-final.yml

[miketsukerman]

@fmoessbauer Thank you for sharing. I will look at your work next week.

[laoshaw]

very useful, we're converting from repo to kas, such tool will be really helpful.

https://github.com/chrysh/kas-scripts has repoManifest2kasYml.py, not sure if it's the same used here, it's 4 yrs old though