The workflows defined respectively in build.yaml and snap.yaml were
both called "CI". On the Github web interface, it resulted in two menus
called "CI" with no easy way to know which is which.
To make things clearer, we now:
* rename build.yaml -> ci.yaml
* call "Snap" the workflow defined by snap.yaml
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
A new job now runs on PRs. It will automatically run mypy on the target
branch and on the source branch. It will generate a diff of the errors,
showing the new ones and showing the ones that have been fixed.
It will also show a summary with the number of errors before/after the
PR.
Because we have so many false positive, it makes no sense to mark this
job red. So we always make it green (unless mypy can't run).
As for now, it's up to developers to go check if any new error is
introduced.
If a line that used to produce a mypy error gets moved, it will be
reported as:
* a fixed error
* a newly introduced error
This is suboptimal and ideally we should have a way to detect moves.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Use fail-fast: false to let the non-failing matrix builds continue to
run. Right now impish is timing out early in the process and we can't
see the results for the others.
Co-authored-by: Didier Roche <didrocks@ubuntu.com>
Canonical employees who have not signed the CLA, and sign commits with
their ubuntu.com alias, fall into a weird gap where their commits are
covered (as employees) but there is no great way for the CLA check to
determine that.
https://github.com/canonical/subiquity/pull/1044#issuecomment-916764603
Chris Peterson