Skip to content

Support loading a configuration file

Peter Hutterer requested to merge whot/mr-label-maker:wip/project-yaml into main

This contains !24 (merged), !23 (merged) and !22 (merged), so will need a rebase, marking as draft for that reason.

This reworks the internal handling of configuration (and adds tests!) so instead of having all label functionality baked-in we now load by default from the .mr-label-maker.yml or .github-ci/mr-label-maker.yml file in $PWD. Alternatively the file can be a URL too, see the --config option. The shortened example of such a file:

version: 1
project:
    name: 'myproject'  # Currently unused but nice to have
    id: 123  # gitlab project id
    instance: https://gitlab.freedesktop.org

issues:
  topics: &topics
    'foo': 'foolabel'
    'bar': ['bar1', 'bar2']

  titles: &titles
    'bisected': 'bisected'
    'regression': ['regression', 'shame! shame! shame!']

  descriptions: &descriptions
    'bisected': 'bisected'
    'regression': 'regression'

merge_requests:
  topics:
    *topics
  titles:
    *titles
  descriptions:
    *descriptions
  paths:
    '^.gitlab/issue_templates/' : ['docs']
    '^.gitlab-ci' : ['CI']
    '^.*/gitlab-ci.yml' : ['CI']

Except for some renaming (I think "topics" is clearer than "areas") it's pretty much the same structure as Mesa.py. But the advantage is that we can now have a scheduled job in any project that pip installs mr-label-maker and then runs it with whatever local config that project needs.

The mesa invocation hasn't changed, it still uses the Mesa.py class though we could easily switch that to yaml as well1.

  1. though given it just runs in an infinite loop we'd then also need some job to re-fetch from upstream and... well, ETIME and EMOTIVATION. ↩

Edited by Peter Hutterer

Merge request reports