Currently our CI setup has a downside: for each push on a merge
request, two pipelines are triggered. The first is triggered in
the context of the forked repository, and the second is triggered
in the context of the MR in the parent repository.
Replace the workflow rules with the ones in the official docs [1],
so that a branch pipeline isn't triggered when a MR exists for that
branch.
[1]: https://docs.gitlab.com/ee/ci/yaml/workflow.html#switch-between-branch-pipelines-and-merge-request-pipelines
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: fbf7fc3517 ("ci: use detached CI pipelines")
This should fix the following problem when I targeted a MR to
branch 'color' in Sebastian's fork of wayland-protocols:
$ ci-fairy check-commits --signed-off-by --junit-xml=results.xml
Traceback (most recent call last):
File "/usr/bin/ci-fairy", line 33, in <module>
sys.exit(load_entry_point('ci-fairy==0.1', 'console_scripts', 'ci-fairy')())
File "/usr/lib/python3.9/site-packages/click/core.py", line 1137, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3.9/site-packages/click/core.py", line 1062, in main
rv = self.invoke(ctx)
File "/usr/lib/python3.9/site-packages/click/core.py", line 1668, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3.9/site-packages/click/core.py", line 763, in invoke
return __callback(*args, **kwargs)
File "/usr/lib/python3.9/site-packages/click/decorators.py", line 26, in new_func
return f(get_current_context(), *args, **kwargs)
File "/usr/lib/python3.9/site-packages/ci_fairy.py", line 1335, in check_commits
for commit in repo.iter_commits(commit_range):
File "/usr/lib/python3.9/site-packages/git/objects/commit.py", line 318, in _iter_from_process_or_stream
finalize_process(proc_or_stream)
File "/usr/lib/python3.9/site-packages/git/util.py", line 370, in finalize_process
proc.wait(**kwargs)
File "/usr/lib/python3.9/site-packages/git/cmd.py", line 447, in wait
raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(128)
cmdline: git rev-list cifairy/color..HEAD --
stderr: 'fatal: bad revision 'cifairy/color..HEAD'
'
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We merged a commit by mistake which doesn't have S-o-b. ci-fairy is
unhappy about it and will fail the check. Skip it if we aren't
running in a merge request context.
Signed-off-by: Simon Ser <contact@emersion.fr>
It's been a few releases that we ship Meson support, we should be
able to drop the old autotools build system now.
Signed-off-by: Simon Ser <contact@emersion.fr>
ci-fairy doesn't know how to to look at $CI_MERGE_REQUEST_PROJECT_PATH
right now, so if we don't manually set $FDO_UPSTREAM_REPO, ci-fairy will
(without verbose logging turned on) silently fall back on the source
repository project path for finding the branch point. This might fail if
the owner of the source repository hasn't updated the `master` branch of
their fork.
Related: https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/32
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This switches to the ci-templates that is found on
https://gitlab.freedesktop.org/freedesktop/ci-templates/
While at it, switch to Debian bullseye, as this contains more reasonably
versioned build tools, i.e. a new enough version of meson.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
