Ulrich Eckhardt authored 6 months ago and Dylan Aïssi committed 2 months ago

Use those for all projects, which works since they are immutable.

Ulrich Eckhardt authored 6 months ago and Dylan Aïssi committed 2 months ago

A rule is applied to a project, which results in actions. A rule itself
does not depend on a project though. This allows generating the rules
once and then applying them to multiple projects.

Ulrich Eckhardt authored 6 months ago and Dylan Aïssi committed 2 months ago

- Set type annotations on all fields.
- Strip `description`, `excludes` and `matches` from the general rule information.

Ulrich Eckhardt authored 6 months ago and Dylan Aïssi committed 2 months ago

- The field `self.rulez` is unused, so drop that dependency.
- The call to `prepare()` is actually mandatory, so we can require
  the according parameters in the constructor already. Further,
  nothing is even prepared there, the parameters are just stored.

Ulrich Eckhardt authored 6 months ago and Dylan Aïssi committed 2 months ago

This makes it easier to understand when actual `Rule` instances are used
and when it is just raw configuration data.

Ulrich Eckhardt authored 6 months ago and Dylan Aïssi committed 2 months ago

- Create a type alias for the GitLab project class.
- Annotate places where that class is used.
- Add a handful of other type annotations.

This is how it should be done idiomatically. Also see the docs:
https://docs.python.org/3/library/__main__.html#main-py-in-python-packages

The linters need to look at a few additional files.

- Add instructions how to run the tool locally.
- Add instructions how to install the tool as a package.

- Using this, you can install the tool with pip:
  `pip install git+https://gitlab.apertis.org/infrastructure/gitlab-rulez.git`
- Version is set to 0.0.0, which is debatable.
- The authors are taken from `git log`.
- The tool can be called as `gitlab-rulez`. This is due to the name in
  pyproject.toml, _not_ the similarly-named script. That script would
  be obsolete by then.

This allows use like e.g. `python -m gitlab_rulez --help`.

- Move actual code to a directory `gitlab_rulez`, so Python can import
  it as a module. Note that it can't use a minus sign as the original
  name, because that would collide with the script and it's not a valid
  Python module name.
- Leave just the call to `main()` in the `gitlab-rulez` script.
- All code is still in a single file, but it could be refactored in the
  future, in particular to separate between the actual implementation
  and the main() function for CLI use.

This was obsolete with python-gitlab 2.x already and removed in 3.x.
Current version is 4.13.0, for the record.

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>

This feature uses the same logic as protected branches.

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Implement the `--output=[plain|json]` flag to control whether
output should be the legacy text one or structured JSON for
further elaboration.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Store the actual project object, the action kind and description
separately in the `Action` objects so we can better process them later.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Switch to `iterator=True`:

    gitlab-rulez:400: DeprecationWarning: `as_list=False` is deprecated
    and will be removed in a future version. Use `iterator=True` instead.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>

In version 1:3.5.0-1 of the python3-gitlab package, a deprecation
warning is introduced.

```
$ gitlab-rulez diff --filter 'sample-applications/*' gitlab-scripts/rulez.yaml
/usr/bin/gitlab-rulez:284: DeprecationWarning:
Direct access to 'gitlab.DEVELOPER_ACCESS' is deprecated and will be removed in a future major python-gitlab release. Please use 'gitlab.const.DEVELOPER_ACCESS' instead. (python-gitlab: /usr/lib/python3/dist-packages/gitlab/__init__.py:44)
  item[key] = getattr(gitlab, symbol)
/usr/bin/gitlab-rulez:284: DeprecationWarning:
Direct access to 'gitlab.MAINTAINER_ACCESS' is deprecated and will be removed in a future major python-gitlab release. Please use 'gitlab.const.MAINTAINER_ACCESS' instead. (python-gitlab: /usr/lib/python3/dist-packages/gitlab/__init__.py:44)
  item[key] = getattr(gitlab, symbol)

...snipped...

```
Signed-off-by: Ritesh Raj Sarraf <ritesh.sarraf@collabora.com>

The apply_changes() function creates lambda functions with a closure
over free variables bound at runtime in a loop. Thus, all the Actions
are setting the same attribute.

Fix this by assigning the free variables at definition time.

Fixes: https://phabricator.apertis.org/T8029


Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>

Replace CI job by a placeholder, it can be updated with something more
sensible later.

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

This is no more requested as `gitlab-rulez` is integrated in the SDK.

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

Apertis rules are provided in `infrastructure/apertis-infrastructure` and
replaced by a simplified one. This allows to push `gitlab-rulez` to Debian.

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Let maintainers push to the protected branches of `tests/` repositories
since it is needed by the `update-binaries` pipelines.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

For projects dropped after a certain release, set the default branch to
the one for the last stable release that shipped it.

Since gitlab-rulez does not really handle rules overriding other rules
correctly, ensure that the rules poking the same setting like
`default_branch` apply to disjointed sets of repositories.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

A couple of packaging repositories needed some custom pipeline job and
to do so they use a local pipeline definition.

The main pipeline now allow for custom child pipelines and that's
what pkg/base-files> is already using, so there's no need for the
special case.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Use a more generic name to later accomodate non-packaging repositories
that can be ignored becaue they are obsolete or not relevant.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>