New elemental packages are not inmediatly consumed by CI

[Itxaka]

Build iso and build raw images are using the default elemental-cli from the releases-teal repos, which means that if we bump them to use new features, they wont be used until the PR has been merged and the artifact published.

An easy fix would be to instead consume the elemental-cli in those steps from the published docker image, as latest should always point to the latest released, so we could cut a release when new breaking changes are done on the cli side and the CI would consume that.

We tried adding the build repo, but due to cross-compiling that would still fail. Like we run the commands on x86, but if we are building for arm64, we cannot use the local build dir as repo, as that will install a wrong arch version.

[davidcassany]

Yes, using the docker image sounds like a reasonable effective and simple solution.

I have also been wondering if we aren't abusing of the manifest.yaml file in elemental-toolkit. I mean, there we have the build stanza that does not belong to an elemental OS manifest, it is just for our own automation:

# Additional packages to build                                                  
build:                                                                          
  - utils/nerdctl                                                               
  - utils/k9s                                                                   
  - utils/jq                                                                    
  - selinux/rancher                                                             
  - selinux/k3s                                                                 
  - recovery/cos                                                                
  - system/grub2-artifacts                                                      
  - system/grub2-efi-image                                                      
  - toolchain/elemental-cli  

I think this should not be part of the manifest and we should handle package builds we need in CI beyond the OS tree in a different way/place. Probably it is enough to strip it to another file. I was wondering about that because I was thinking on building the CI dependencies separately always with the host arch, not the target arch.

Also something that is probably worth double checking is why, with the current setup, luet attempts to install packages from another arch on cross builds, the expected behavior should be that packages are simply not found. Looks like we might have a wrong (or not precise enough) repo configuration somewhere.

[Itxaka]

Couple of things, first, I don't think we are using that package list anymore as we use the build.go facility to identify packages missing and build those so it should be easy to drop. Second is that in order for luet to enable/disable a repo based on arch, the repo must be disabled and have a arch key. Then it compares it to the running arch and if they match it enables it. That would allow us to have it on the deps_ci part and automatically enable/disable stuff. Not sure how would that affect cross repo builds, as we don't use the system repos it should be safe enough.

[davidcassany]

Couple of things, first, I don't think we are using that package list anymore as we use the build.go facility to identify packages missing and build those so it should be easy to drop

Cool, I though we were still using this.

Second is that in order for luet to enable/disable a repo based on arch, the repo must be disabled and have a arch key. Then it compares it to the running arch and if they match it enables it. That would allow us to have it on the deps_ci part and automatically enable/disable stuff.

Yes I was thinking about this kind of details, probably we can configure local built repository with the proper arch and, at least, prevent the weird errors of trying to install packages from another arch. I don't think this magically solves cross-builds either, but should not hurt.

[kkaempf]

Not considered urgent enough to work on. Will be reopened when needed.