08:25 <mcon> What is the GitLab-CI "best practice" to have two similar pipelines one doing incremental build (at each commit) and one doing a full rebuild (nightly), both followed by the same deploy(needs build artifacts) and test stages?

08:26 <mcon> Sorry I keep asking OT here, but on #gitlab there seems to be none knowledgeable willing to help :(

08:38 <kranzo[m]> mcon: so you got your artifacts download working? actually not limiting the artifact download by the dependencies key and just filtering (rule/only/workflows) in the build stage should do the trick. So all later stages will get the artifacts not matter what job produces them in the build stage

08:40 <mcon> kranzo[m]: Yes, pipeline is basically working. Thanks.

08:41 <kranzo[m]> may i ask what solved the problem? :D

08:44 <mcon> kranzo[m]: I tried asking also on https://stackoverflow.com/questions/68877379/how-to-define-a-gitlab-ci-job-to-depend-on-either-one-or-one-another-previous-jo but no takers yet. I find all this GitLab-CI quite difficult to understand; I didn't find docs to bridge from trivial examples to plain list of available tags :(

08:48 <mcon> kranzo[m]: Apparently just using "artifacts:paths" (with trailing slash) on producer and "dependencies" on consumer is enough. If you want I can post the whole pipeline gor your reading pleasure ;)

08:49 <kranzo[m]> i allways like a good ci :D

08:49 <kranzo[m]> do you realy need the dependencies keyword?

08:55 <kranzo[m]> if you can drop the dependecies, the artifacts should be available in the later stages not matter what.

08:55 <kranzo[m]> https://docs.gitlab.com/13.12/ee/ci/jobs/job_control.html

08:55 <kranzo[m]> here you can limit the nightly builds (i.e schedules only) and exclude the incrementals from that runs.

09:01 <mcon> kranzo[m]: my current .yml is at https://dpaste.org/5pUR The incremental build seems ok, but it's unclear to me how to tell GitLab deploy and test should be run even when I manually trigger build-nightly

09:09 <RP> anyone fancy debugging qemuppc's serial interrupt handling?

09:16 <kranzo[m]> mcon: https://gitlab.com/kranzo/ci-test/-/blob/20d9c246ca71b296c61c0ec9f7e457c6014ce423/.gitlab-ci.yml

09:16 <kranzo[m]> this one is limiting to web, but you could limit on other refs:

09:16 <kranzo[m]> https://docs.gitlab.com/13.12/ee/ci/yaml/index.html#onlyrefs--exceptrefs

09:19 <kranzo[m]> you can check the build/build-manual jobs the last 2 pipelines

17:11 <vd> hi all -- my project is compiling fine on my machine even with a fresh TOPDIR (shared SSTATE_DIR though), but CI fails with `ldns_1.7.1.bb:20: unparsed line: 'do_install:append() {'`

17:11 <vd> It looks like this is the new override syntax that I'm not yet using, I'm still on hardknott

17:12 <vd> Is it possible that some layers (bitbake itself maybe) merged the new override syntax within 2021-04-hardknott, or OE-Core/meta-openembedded in their hardknott branch?

17:18 <vd> RP: ^

17:46 <manuel1985> vd: Are you sure the CI is using the same commits as your local build?

17:50 <vd> manuel1985 it should, I'm using kas with hardcoded branch names for every layers

17:51 <manuel1985> vd: kas is tricky, we ran into issues there

17:52 <manuel1985> vd: Perhaps you need the --update switch https://kas.readthedocs.io/en/latest/command-line.html#Named%20Arguments_repeat1

17:53 <manuel1985> I think without the --update it doesn't notice when a branch is moving forward. But that's just a guess.

17:57 <vd> let me try that

17:59 <vd> The CI is indeed pull fresh repositories compared to my local setup, so that would make sense actually

18:00 <vd> manuel1985 thank you! I can reproduce the error locally. now I must find the faulty repo and hardcode a previous refspec...

18:33 <vd> here's the faulty commit: https://git.openembedded.org/meta-openembedded/commit/?id=bca3bbbf203086794e5b56a71c04a7bbc59f9bea

18:33 <vd> khem ^

18:37 <vd> which wrongly uses the new syntax in the hardknott branch

18:51 <vd> Same with the commit above from the same author

20:00 <manuel1985> Can anyone tell me what this line is doing? FEATURE_INSTALL = "${@' '.join(oe.packagegroup.required_packages(oe.data.typed_value('IMAGE_FEATURES', d), d))}"

20:01 <manuel1985> From core-image.bbclass

20:02 <manuel1985> I just can't comprehend where IMAGE_FEATURES trigger appends to IMAGE_INSTALL

21:17 <RP> vd: if you use the latest on the bitbake branch you're using it should parse that

21:28 <vd> RP: that's not the issue here. The problem is that the hardknott branch of meta-openembedded has two commits (linked above) wrongly using the new syntax.

21:35 <RP> vd: that is bad but if you use the lastest bitbake from that release series, it will work ok

21:55 <vd> RP: do you mean there is retrocompatibility with the _override syntax? because I'm still on hardknott

21:57 <RP> vd: yes, have a look at the top couple of commits to https://git.openembedded.org/bitbake/log/?h=1.50