I think you can do this with a little help from devtool: devtool upgrade component devtool finish component layer-path git add/commit layer-path bitbake component
This has the added benefit of keeping things deterministic and reproducible. You can further automate these steps with help from AUH: https://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/about/ Alex On Thu, 9 Jan 2020 at 11:52, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Wed, 2020-01-08 at 13:10 +0100, Pascal Huerst wrote: > > I'm looking for a way in yocto to build tagged releases or actually > > to build the newest tagged release from repositories. > > > > There is a way to specify a branch or a tag in a recipe, but no way > > to always clone the newest tagged release, that I'm aware of. I > > submitted a patch to bitbake's mailing list with a proposal [1], that > > would use bitbake's `latest_versionstring()`, to always find, fetch > > and build the latest tagged release. Unfortunately there wasn't much > > of a reaction on that proposal, so I'm taking a step back, collecting > > ideas on how this could be achieved properly. > > > > Please share your ideas... > > I did look at and think a bit about your patch. The trouble for me (as > the bitbake maintainer) is that: > > a) it isn't clear/obvious from the variable name what it does (or even > from the code) > b) it adds yet more options to the fetcher which increases the test > matrix and possible ways things can break > c) the test doesn't actually test it does what its supposed to (no > check is made on which output is downloaded for a given revision) > > Some of these can be fixed, some are much harder and I can't decide if > supporting this kind of edge case is going to be an overall good thing > for the project or not. I don't want to give you false hope by fixing > c) only to say "no". > > Add in Khem's valid concerns about reproducibility and it makes it a > tough one even to give feedback on. > > If we have a ton of users saying "yes we really need this", that would > help but I haven't seen that as yet... > > Cheers, > > Richard > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core