search

siemens / kas

Setup tool for bitbake based projects
MIT License
353 stars 144 forks source link

${AUTOREV} for `refspec` #35

Closed HerrMuellerluedenscheid closed 3 years ago

HerrMuellerluedenscheid commented 3 years ago

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 a refspec=${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

jan-kiszka commented 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.

pbrkr commented 3 years ago

@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?

HerrMuellerluedenscheid commented 3 years ago

@pbrkr awesome! Yes, that helps a lot!

henning-schild commented 3 years ago

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.

pbrkr commented 3 years ago

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 :)

embetrix commented 1 year ago

I would be nice if kas can provide an utility to help setting the rolling refspec to fixed commits automatically when releasing.

fschrempf commented 1 year ago

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: