It's more annoying than useful to have to wait for the first stage
before the second stage (pytest) starts. I'd rather have the whole
pipeline run through quicker and see if there are python errors too even
if linting errors are not resolved yet.
In pmaports.git this makes more sense: there we have "lint" and "build"
and in the worst case "build" may take up to three hours. So it makes
sense to only start it if there are no cosmetic errors. But that's not
the case here.
CI started failing with:
/builds/ollieparanoid/pmbootstrap/venv/bin/python3: No module named pytest
I've briefly tried to fix this with the existing scripts. However,
instead of investing more time into that, do the long overdue
refactoring of the scripts that involve dropping the venv logic and
support for a custon gitlab-ci-runner using some python docker image as
base. This configuration hasn't been used for a long time and is
probably broken anyway.
Refactor the logic to skip the qemu test case in gitlab CI by using
pytest markers. The new script is now similar to bpo's .ci/pytest.py.
Make sure that features requiring a higher python version don't sneak in
by accident.
It would be nice to add this to test/static_code_analysis.sh, so it is
easy to run it locally. But vermin is not packaged in Alpine right now,
and given that this should be a rather rarer error, it doesn't seem
worth the effort right now.
Run silently by default and only in verbose mode if there are errors,
because if vermin isn't silent, it will not just point out errors, but
describe required python versions for everything it sees. (Copied that
part from the bpo CI script, where I had used it as pre-commit hook as
it was stuck on 3.5 for some time.)
Two "su pmos -c 'git config --global user....'" commands were added to
the before_script in .gitlab-ci.yml. They work fine with the regular
gitlab runners, but fail with the custom gitlab runner that runs the
qemu test. Simply allow the command to fail, because it isn't needed on
the custom gitlab runner, as it doesn't run related tests.
Fixes: 16e2d3c77c ("gitlab-ci.yml: set git user/email (!1848)")
In gitlab, there is no extra CI job running for commits in a merge
request (MR). This means, we can't run different code in a MR against
"master".
So instead of only checking whether all devices are booting if there's
a MR against master, always perform this check.
I've edited the message slightly, so it's clear that it's only required
to have the devices booting when making a merge request against master.
This uses a variable configured in the gitlab project [settings->CI/CD->Variables]
to restrict when the qemu job will run. This should prevent the job from running
on repo forks where an appropriate runner has not been configured/registered.
Note that if this variable is set in a repo where there is no runner registered to
run qemu, then any CI jobs in that repo will ultimately fail the qemu tests since
no runner will be found.
Oliver Smith
Maxim Karasev
Clayton Craft
Daniele Debernardi
Steffen Pankratz
Oliver Smith
Clayton Craft