chore(scaffolder-backend-module-gitlab): Upgrade to gitbeaker ^41.2.0

[mpsanchis]

Hey, I just made a Pull Request!

Upgrade gitbeaker to ^41.2.0 (major version) in scaffolder-backend-module-gitlab.

First split of #27360 as requested.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@backstage/plugin-scaffolder-backend-module-gitlab	plugins/scaffolder-backend-module-gitlab	minor	v0.6.1-next.3

[backstage-goalie]

Thanks for the contribution!
All commits need to be DCO signed before they are reviewed. Please refer to the the DCO section in CONTRIBUTING.md or the DCO status for more info.

[CptnFizzbin]

do you know if this update would fix the error messages from GitLab (as I reported in #27600)

For example when trying to create a branch via the API, if there are branch name rules configured, the error message is added to a description field instead of the error's message

[mpsanchis]

Hi @CptnFizzbin
I haven't tried it, I'm not sure. In fact this PR is a "prerequisite" for me, because I want to add a feature that only newer versions of Gitbeaker support. I have done the bare minimum to do the upgrade (ideally I would have only modified package.jsons). Feel free to give it a try and let me know 😄

[freben]

Alright, looking good, just minor questions

[freben]

Hm. Is this a good thing being the specific strings? Is this truly the only possible scopes now and forever? :)

[mpsanchis]

Up to you guys :) Having it as string allows "unwanted" behaviour for now, but of course the user will quickly realize.

I'm happy to leave it as a string. Should I cast it as DeployTokenScope in createGitlabProjectDeployTokenAction when calling api.DeployTokens.create?

[CptnFizzbin]

might be good to list out the known good ones, and have | string tagged onto the end. Would allow intellisense to suggest these values, while also providing an escape hatch (and type hints) that there could be more options in the future.

[freben]

Yep that's a good middle ground. Will still need a cast internally but is useful to the end user.

[mpsanchis]

Can you give me a hand on this, guys? TS considers some types as "subtypes" of others. For instance:

let a: string | "read_repository" | "read_registry" | "write_registry" | "read_package_registry" | "write_package_registry";

is equivalent (in VSCode suggestions) to:

let a: string;

With zod, these types would be generated with:

scopes: z.array(
  z.union([
    z.enum([
      'read_repository',
      'read_registry',
      'write_registry',
      'read_package_registry',
      'write_package_registry',
    ]),
    z.string()
  ]),
  { description: 'Scopes' },

But I get no benefit with intellisense, and the API report will declare string[].

I'm good with reverting it to string[]. It looks like the only viable alternative.

[mpsanchis]

I'm pushing it with string[] for now. If you like it, we continue like that. Otherwise let me know and I change it to DeployTokenScope[] (or maybe a 3rd option?)

[CptnFizzbin]

leaving it as string[] is probably our best bet

[freben]

Wait where did this come from? :) I don't think I see it elsewhere in the code and this is an autogenerated file eh?

[mpsanchis]

Indeed, it was generated automatically! 😕 It has nothing to do with my changes, that's why I kept it in a separate commit.. However, if I remember correctly, CI was checking that these api reports in my code match the generated ones, and this one didn't.
I can delete this, but I'm pretty sure it'll fail in CI.

How can I proceed?

[freben]

Nah leave it in if that's how it got generated. Curious thing tho 🤔

[mpsanchis]

Now it wasn't added anymore by the api report generator.. weird 🤷

[freben]

seems to need a rebase now too after the other PR got merged

[mpsanchis]

@CptnFizzbin & @freben it seems that CI is green now 😄 Do we stay with the current state? Or do you want something else from my side?

[github-actions]

Thank you for contributing to Backstage! The changes in this pull request will be part of the 1.34.0 release, scheduled for Tue, 17 Dec 2024.