GitLab Pipeline Insights Group, 24 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: CI_JOB_TOKEN discussion 2023-07-24

Description

Sync discussion to decide the direction with an ongoing MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121750

A

Cutting this 24th of July and we are meeting to discuss the details related to CI job token, access with groups in general um and, like there have been there's been a lot of conversation that went on in the merge request that was created by Marcus, and uh we just want to like make sure that we agree on the direction forward: um yeah, okay, let's so my first question I mean I'll vocalize what uh Fabio has mentioned, so he says that the suggestion from Marcel the most recent one where um we are adding a toggle to allow all the projects in the same group to have access um to this particular project, um to provide a checkbox together, is a good starting point.

A

The same, however, can be achieved if we allow the project to allow list an entire group. The project adds its top level group to the allow list. Now, I have a question regarding this, and I am also going to like share my screen.

A

A

Foreign by the way here is the proposal that we are talking about so Marcel mentioned like if we just add a check box uh here that says that give access to the projects in the same group to the group that this particular project belongs to. So that's what uh we explored here and um based on Fabio's comment, which is like the same, can be achieved if we allow us the project allow the project to allow list an entire group. The project adds its top level group to the allow list. Now.

A

Does that mean that the very first design that I worked on was right, which.

B

A

In this particular one I mentioned that users can add both groups and project to their allow list and uh like we can just differentiate uh between those in the table uh by mentioning the namespace okay.

B

Maybe this does.

A

B

I think that um I think that makes sense to me I mean we could also have a separate, um separate list for groups. I guess, but differentiating them by a Nikon probably makes sense um I. The only thing I worry about is, if there's any conflict between like I guess, there's no way like there would be a conflict between like the group, The Project name and the like a group name. So, oh.

A

Marcel is here yay, because Marshall did have some questions about that approach. So uh Alison, if you can repeat your question, I think.

B

um I was just one worrying out loud that there might be conflicts between a group and project path, but that shouldn't be the case. uh Thinking about it a little bit more um so I think it's kosher to use the same UI for both like not have separate lists.

B

Okay, um instead of the project path,.

A

Got it the muscle to summarize uh what Allison is talking about? um We looked at Fabio's comment that uh the suggestion that you had provided that I worked on here uh and added this uh toggle to give access to projects in the same group. The same can be achieved if we allow, uh if you are the project or Lawless to an entire group.

A

Now there was a proposal that I worked on like a few comments before which kind of suggested the same, like you can paste group or project path here and add both like should be able to add both to allow list and Alison was just mentioning whether or not like she was just thinking out a lot if both can be shown in the same list or we need to separate out the list for grouper project but uh I. Remember you having some concerns with the overall approach here in this comment.

A

If you want to like talk about it,.

C

Yeah sorry I'm late there took a while to get the kids to bed. um I didn't actually have any real concerns with the approach. Yeah I think it was a little bit above that that some other people had concerns and I was like I, actually think it'd be great to be able to add a group in the end, and there were some different discussions about projects versus groups and- and uh let me just scroll up I'm looking at it right now as well.

C

Just trying to refresh my memory.

B

Yeah I haven't really followed the whole conversation here and read through this totally so.

C

Basically, my idea is just that there was a whole bunch of discussions about multiple groups and projects and I think permissions, and things like that and I was just just throwing out an idea trying to reduce the scope uh to um just a single group, and uh it's just basically what would I want and in the docs project, generates review apps from five different projects, but all of those projects are in the same group as the docs project.

C

So for me, all I would need would be a toggle to say any of my neighbors can trigger pipelines in this project. So that's just basically what I was thinking like throwing that out there like. Would this be a smaller MVC, uh but then yeah Fabio said yep. That would be a great as an MVC.

C

But if you just allow people that any group they could, they could add the group that they're part of into an allow list and it would achieve the same effect, which is totally true as well so um yeah. That's all I was thinking just just an idea to potentially reduce the scope, but not not something that I think would be would be better or worse. Just smaller.

A

D

um Yeah the thing with doing groups is right now like we're getting so uh so much I'll call it feedback um from our customers right like when we're gonna change the until you change the behavior in 17-0 and so I think. If we were to do it by groups like that would be more lovable concept um and.

D

Like it would, it would really uh I think reduce a lot of the heartburn um as well like and so I don't know if it's worth doing like an interim step with just projects because like right now like that's what the complaining is about.

B

Yeah I do agree, though I mean I, I haven't done like customer interviews or anything obviously, but I sort of agree that, like probably a common use case, is just within the same group. But from my perspective from the back end, I would still develop that button with the capabilities of adding any group to the allow list like that would just be the way I I. Don't think it would be much more work either way from a back-end perspective.

B

So I would probably be asking a front-end engineer how much harder it would be, to like add a toggle versus um versus um adding groups to the allow list. But my suspicion is that it's not that much um of it. It's not that much harder to do the allowed list.

C

Version the way I was guessing was that people on SAS would prefer just the the toggle, because I think a lot of the paid customers. They just have their own namespace and they can just say well just add my my group to the uh to- or just you know, enable the toggle for my local group, but then it would be more for um self-managed where they would have. You know multiple groups and things and a whole variety of you know different ways that they could set it up.

C

So I I think the taco would be a quick win for SAS, but the allow list would be a win for everyone, but more specifically useful for self-managed is it's my suspicion.

B

My only other concern is like if we did develop the toggle like what then happens to like it does seem kind of nice to me UI perspective. But what happens when you have the the two things conflicting like you? Have the group added to the allow list, but then the toggle doesn't agree.

A

Yeah I was thinking about that and that might complicate things a little, not a little.

C

Yeah, that's a great point.

A

I am in favor of like directly developing uh the capability to add groups, because uh that might save us some time in reworking on a certain things.

D

Yeah I think we should just go and go for groups.

A

So in that case, what do we do with the current ongoing magic West.

B

I, don't have a lot of context in that, um because I've been working on AI stuff, so I haven't really been involved in that one um I'm not sure who's reviewing it currently. Is it Fabio.

B

Yeah, it looks like Fabio did a review on it.

B

What is the current Mr doing.

A

um It started off with the like, with the proposal uh to allow app wait. What was that.

C

I just watched the video and it seems like it's just it's using the same interface, but you instead of putting a project path, you'd put a group and then it would just put all of the projects in the list of the project. So it would still be you would put in group and all of the projects within that group would then populate into the allow list. So you're, not adding a group you're, adding all projects of a group to the project. A lot list.

A

C

D

A

Appear as groups like they, but all the projects are from inside. That group will be listed, which is fine until like one has to.

D

No yeah I, don't like that move.

A

C

A

C

Someone adds another project. Does that to the group? Does that show up or not yeah.

D

B

Yeah I think that's a bad approach, because if they have to go delete them one by one, that's going to be really hard and then also um it's just yeah. We have a hundred as a limit right now so for like really big groups that might just be broken immediately.

D

Yeah I, don't I, don't like that Approach at all.

B

So I think perhaps we should like coach him towards this approach and it actually seems like Fabio's, already kind of done, that to a degree of adding a group um rather.

A

B

Trying to add a group and it adds all the projects. um It looks like his comment on that.

A

Mark does that that's when I also created this issue and added a proposal um this one, uh uh the one that I had showed that allows adding groups. It was like a part of the same Mr like from here I thought: there's a need to document it and created that. But then we like changed the approach a couple times and um I. We can either like go back and uh request Marcus to like take the follow the same design or.

A

Or close DMR would that be a lot.

C

I I would say like like just change the design and just say you know this is the requirement. This is what it what it has to be. Unfortunately, like we appreciate it, what do you want to do, um but it does like it does have to follow this design. So, if you'd like to work on it great, we can coach you with it.

C

um If, if we've taken it down a path that you don't want to work on it anymore, that's fine! We we appreciate the um the work that you put into it.

D

A

That sounds like a plan: um I can or Justin can uh draft like a message there and see what happens. Oh.

D

Yeah I can be the bad person.

A

D

Kids have taught me well.

C

You you can I I had something recently like this, where you can say like thanks to you for opening this, we were able to talk about it and come to a better solution than than we had thought originally. So, despite it not being merged, it was still useful to us, and we appreciate that.

A

D

A

That for one of the recent merge requests, um it was for.

A

Yeah um overriding variables, UI checkbox,.

D

Oh yes, that one.

D

A

Cool yeah, I'll drop it and then I'll sounds like we have this uh plan in mind. Okay, the knowledge is good and I'll. Stop the recording here.