search

heinezen / thunderdome-api

Scripts for automating work with the Thunderdome API.
GNU Affero General Public License v3.0
3 stars 0 forks source link

Fetching GitLab Issue data fails when its project is in a subgroup #2

Closed heinezen closed 2 weeks ago

heinezen commented 3 weeks ago

Description

When fetching the Thunderdome battle plans, the script processes a link to the GitLab issue and tries to get information about it from the GitLab API. The link is matched against a regular expression to 1) make sure that the link is a valid GitLab link and 2) extract the project ID from the link for the API lookup.

https://github.com/heinezen/thunderdome-api/blob/12d78d59c33e40110ff7b22bd0d345453c3a9400/main.py#L32-L35

The current issue with this regex is that it doesn't account for the existence of subgroups. Thus, any issues that are part of a project in a subgroup will fail to validate, even if they are valid GitLab links. For example, this link wouldn't work:

https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/261

The subgroup papers is not accounted for by the regex.

How to Reproduce

  1. Create a new Thunderdome battle
  2. Add a new item with a link to an issue in a project in a subgroup.
  3. Run the script with the fetch command using the created battle as the source
  4. Observe that issue validation fails with a message like this:
Skipping plan Test: Invalid URL 'https://gitlab.gnome.org/GNOME/Incubator/papers/-/issues/261' does not match GitLab URL pattern 'https:\/\/gitlab\.com\/(?P<orga>[a-zA-Z0-9\-\_]+)\/(?P<project>[a-zA-Z0-9\-\_]+)\/-\/issues\/(?P<issue>[0-9]+)'

Expected behaviour

Link to GitLab Issues from projects in subgroups can be matched with the regex.

Potential Fix

Amend the regex with a pattern for subgroups, e.g. ((?P<subgroup>[a-zA-Z0-9\-\_]+)\/)*