Closed HerrMuellerluedenscheid closed 3 years ago
@pbrkr is using an auto-update model for CI purposes and can probably share some best practices in the kas context. All our layer dependencies are currently pinned.
@HerrMuellerluedenscheid: In a kas config file you can specify a commit hash, tag or even a branch in refspec
.
A good example may be what I do in the meta-sancloud layer. We have a "rolling" configuration in kas/dev/bbe-poky.yml
and kas/dev/bbe-arago.yml
(the two distros we support) with refspec: dunfell
, see https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/kas/dev/bbe-poky.yml for example. Then we have a "release" configuration in kas/bbe-poky.yml
and kas/bbe-arago.yml
which specifies fixed commit hashes to use for each layer, see https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/kas/bbe-poky.yml for example.
Does that help?
@pbrkr awesome! Yes, that helps a lot!
Note that "branch" tracking is not supported. So using a branch in kas can get you stuck on a "random" commit ... depending on when you first ran kas to clone. So using branch-names as refspec is something you can do in CI ... where you hopefully start rather clean every single time. But for all other cases tags/branch-names are a bad idea, shas are the safe bet.
Note that "branch" tracking is not supported. So using a branch in kas can get you stuck on a "random" commit ... depending on when you first ran kas to clone. So using branch-names as refspec is something you can do in CI ... where you hopefully start rather clean every single time. But for all other cases tags/branch-names are a bad idea, shas are the safe bet.
This is why I added support for the --update
and --force-checkout
arguments to kas :)
I would be nice if kas can provide an utility to help setting the rolling refspec to fixed commits automatically when releasing.
I would be nice if kas can provide an utility to help setting the rolling refspec to fixed commits automatically when releasing.
Indeed, that would be helpful. I have the following maintenance helper tasks in mind:
Hey, I usually now work within our proprietary meta layer within the downloaded kas sources. I update things, run
kas build
, if everything works fine I update the kas configuration with that latest commit. To enhance that workflow I was wondering if arefspec=${AUTOREV}
given that a branch (or if not fallback to master) is provided wouldn't be an option. Sure, explicit is better than implicit. On the other hand we already know (and I love) the${AUTOREV}
feature from bitbake during development.Best Marius