pmbootstrap used to exit with 0 if "pmbootstrap lint" failed. This was
the case in 2.3.x too, but I assumed this was a regression and fixed it
recently in pmbootstrap MR 2398.
It turns out that the CI code relied on this assumption, it captured the
output of "pmbootstrap lint", and only after it is done it checks if the
output wasn't empty and prints it in that case followed by exit 1.
Now that pmbootstrap actually exits with 1, CI already fails at
"common.run_pmbootstrap" and doesn't get to the part where it would be
printed.
I think "exit 1" on error is actually the right thing to do in
pmbootstrap, so I'll leave that in. Adjust CI to just run "pmbootstrap
lint", removing the additional output capture logic that isn't used
anywhere besides here. This also has the advantage that we get the
output "live", without buffering it completely first.
I was confused for a while about why the SHA printed by CI differed from
the actual upstream/master SHA:
commit upstream/master: f822b7ee0d06f05ff6d2eb37bcf4a1825569be692
real upstream/master: 822b7ee0d0
This prefers gitlab CI's target branch from the env, and falls back to
the old target branch detection mechanism (using pmaports.cfg, etc) if
it's not set. This fixes CI in gitlab where the target branch is
something different than expected, e.g. if using stacked branches.
[ci:skip-build]: already built successfully in CI
In 11682fb0ab, the timeout was set to 10
hours. This means that the CI no longer just runs for one hour. However,
we are still limited by GitLab's runners which only give us three hours
of CI time per job, so given the status quo, this is the most likely
duration for someone who hasn't set up their own CI runners.
Adjust all CI scripts that make use of .ci/common.py to
'pmbootstrap ci'. Move all scripts that are not direct entry points to
running CI scripts to .ci/lib.
Comment out the dtb check, as it is failing. Apparently it didn't run
properly before. Let's fix this after this CI change is done.
