Add GitLab support

[MarcoIeni]

Motivations

release-plz supports GitHub and Gitea. I'm not familiar GitLab, so I haven't add support for it. However if you want to use release-plz with GitLab, tell me how the integration should work.

Here are the API calls we use for GitHub and Gitea. What's the equivalent in GitLab? Should we create the equivalent of the GitHub action for the GitLab CI?

We need to add support for these commands:

• [x] release-plz release (see https://github.com/MarcoIeni/release-plz/pull/591)
• [ ] release-plz release-pr

[D-J-Harris]

What is the status of release-pr command not being ready? I see there is some support in core for it

[MarcoIeni]

The support in core is for the release-plz release command. Regarding the release-pr I don't even know how release-plz should work on GitLab, as I'm not familiar with the platform (how PRs look on GitLab?). I also don't plan to work on this, since I don't have a use case for it (see the priority:low tag). Of course, I'm happy to help someone who wants to work on this.

[magikmw]

I'll carve out some time to take a look, at least to provide some gitlab usage knowledge and feedback on what needs to be done for their API.

I do have a specific question - how likely are we to use a dependency specific to gitlab API (if one exists in rust, so far I only used a python implementation)?

[MarcoIeni]

Thanks for that! I would like to avoid using a gitlab library to keep the number of release-plz dependencies low (we don't use libraries for github or gitea as well).

If you want to raise a PR and you want to use a gitlab library for fast-prototyping, feel free. We can remove the dependency later. 👍

[mbodmer]

Suggestion: I think it would make sense for release-plz to embrace API Client libraries like: https://crates.io/crates/gitlab, https://crates.io/crates/github and https://crates.io/crates/gitea for backend support. release-plz does a great job integrating tools and manage the process, but supporting different APIs which can be moving targets shouldn't really be it's job. Also it can only support a subset of eg. auth tokens: https://gitlab.kitware.com/utils/rust-gitlab/-/blob/master/src/auth.rs?ref_type=heads#L50 as it wouldn't make sense to re-implement everything. Alas it would be handy to have it all, as provided by these libraries.

[MarcoIeni]

Reasons why I don't use third party http git clients:

• adding dependencies increases compile time. If in the future we support more git hosting providers (bitbuckets, etc.) we need to add one library per provider. I only use a small subset of their api interface. Adding a library means compiling their whole api interface, which takes time and makes development more frustrating
• some api are the same. E.g. Gitea and github are very similar. So with one http call I can cover two hosting providers. Instead with two different libraries I need to call two methods
• I'm in full control of the http call. E.g. I use reqwest-middleware to automatically retry all http calls returning certain status codes (e.g. 500s). Ensuring a consistent behavior among all crates would be a huge effort.
• I want to read the docs of the hosting provider (github, gitlab, etc), not the docs of the library author because I want to make sure I'm reading the best and most up to date version of the docs
• adding such crates decreases the security of release-plz. We are passing auth tokens to these crates. What if they are compromised?
• what if a crate becomes unmaintained? The github crate you linked hasn't been updated in 9 years.
• what if I need to add a new api call that's missing from the crate? I need to raise a pr and wait for it to be merged. This decreases the velocity of release-plz

Sorry for the brain dump! I hope it's more clear why I don't use third-party git hosting libraries. I should document this properly in contributing.md 😁 Thank you for the suggestion anyway. I understand it's a controversial topic and there's no right answer

[mbodmer]

1651