GitLab Pipeline Execution, 9 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-02-09: Pipeline Execution Community Office Hours

Description

Agenda for today:

1. Direction updates on where this feature is going from the GitLab Side - James https://gitlab.com/groups/gitlab-org/-/epics/6378
2. Architecture/data store changes needed to support / align with community work - Caroline
3. Q&A / Sync MR review

A

This is the pipeline execution team's office hours for February, 9th 2023 um our topic today uh and the agenda is the Epic figure CI minute limits, project and subgroup.

A

um I'm gonna go ahead and share my screen uh with the Epic just to talk through um where the feature set is going and kind of recap what we talked about last time, um everything around uh so the larger problem to solved with this epic is really allowing namespace admins and for self-managed instance admins to get a more granular level of limits on projects.

A

um So there's a case specifically from the Drupal Community who's running a self-management who wants to limit within subgroups or project the amount of CI minutes they can consume per month, um which totally support that. um So we had some Community contributions. That came in initially to support that. um But there's uh there's some confusion in the code, probably um around quota versus limit and what is applied from the license down, um and so the contribution would have circumvented um the license uh quota that is set on kitlab.com users and against the shared stats Runners.

A

And so we put a pause on those Mrs uh just to kind of take a step back to find all the use cases that we wanted to address and make sure that we had the issues created for those and so now, I think at this point we have all of that in the Epic and a couple of different ways to think about it um uh in tables and an issue list and in diagrams um to try to kind of set out quota is what comes with your license and it is applied to you this year.

A

Fast Runners, um that was the number of purchased minutes is what is applied within that. We want to allow namespace admins to set limits of how many of those projects and student per month uh and so try to sketch that out within the hierarchy within this diagram, and then we have a good list of the issues here and kind of an implementation phase plan uh to a purchased and to set this up and I.

A

Think that the first thing that we would want to tackle is really the uh the Drupal use case of setting that cicd limit per project on self-hosted infances. um And so that's the issue here and then doing that within a subgroup again Crystal hosted. We may find that that those two issues cover both for still posted and for staff, but as long as it um applied to you know within that quota for those SAS users that were in a good spot.

A

So before we move on that any questions about kind of the larger goal or some of the things that have changed since black time we held in community office hours or if you have additional questions um from the discussion we've been having in the issues in the epics and the Mrs.

A

All right, well I'm, going to hand it over to Caroline and Drew to talk a little bit through some of the technical details of where we want to store these things and the nouns of that. um As our next topic on the agenda.

B

Okay, I'm actually going to pass it over to Drew directly. um We went through it yesterday and we I think we have uh some good technical guidance um based on our reading of the issues. I.

C

Will send I'm gonna, put a merge request, link into the zoom chat for everybody right now, um I'll be sharing my screen and walking through and pointing at stuff. But just if you people want to hold on to that and poke around and look at other stuff, while I'm talking feel free.

D

All right, okay,.

C

All right, so this is a a sort of draft that Carolina and I worked through that doesn't we did not cover like the mechanics of how to set them? You know like which API like what the endpoints are going to look like that's stuff, that we would leave up to implementation and when we ran it when we were working on this before the the problem James mentioned about, you know like oh well, suddenly, you're purchase CI minutes won't matter.

C

uh We we're focusing on like, what's the design of that, gonna look like to make sure that you know everything else will will not. You know, break some of our existing logic and.

C

Largely the the difference in the difference in the way we designed this draft is that we have um we've sort of implement a a hard limit that can like be set at any level in a group in Project hierarchy and then We. Compare that limit that that's the thing we're talking about, adding that could be configurable based on your top level namespace. It would be a default for everything within a namespace and a subgroup.

C

You can configure something different, um but at the individual project level, where we say in this project like what's the number of minutes where we stop processing and I promise I'll explain this and it won't look. It won't look like it does now. You might feel better about this, but um essentially a project can have here an explicit limit from an admin that says this project gets 537 minutes. That's it.

C

um We compare that to an inheritable limit that can be set on any group in its hierarchical chain, and so this will get passed down. If you ask a namespace what it's CI hard minutes limit is, it will say you know it will say it it'll give you its own or its parent group, whichever is lower um and we take the lower of those two if they exist and if not we use, and- and these are sorry to be clear- these are the direct like they'll.

C

We take the lowest of any number if somebody configures this for subgroup B, it affects it is the hard limit for everything in its projects in subgroups of that subgroup like that, that is a that's like a rule set top down. There's also down here.

C

There's a separate inheritable default, which is I, think something that Drupal is interested in that, if it's sort of saying, if there is no discernible default, not just that it's more or less like, if there's nothing in these two hard limits, uh just use this one instead and so the the use case of you know, we have 30 000 projects and we'd, like all of them to have a limit of 400, except for a few that we go and specify, but like mostly it's 400 .. um This would be configured to 400.

E

And that's exactly right to describe our use case on the sort of Drupal scenario. Yeah.

C

Great, um thank you. The the important difference here is that this is not selected as using a grader less than comparison. So like these two hard limits you take, the least of which is sort of a hierarchical permission, thing right where, if a, if a top level subgroup says this is the limit, no subgroup can decide to use more if they don't.

C

If this limit is specified to 400, broadly across whole organization, multiple subgroups, you could still come in here and say: well, this one project gets thirty thousand, and if we have it, we will not use the default.

C

So there's there's the explicit hard limits that are always limiting it'll look up. You always take the lowest limit that you see in your. You know, reporting in the group hierarchy um and then this is. This only applies. If there's nothing, if there is no hard limit in the hierarchy at the project level, we will then take whichever value. We've decided. Is the right one from those three and compare it to a purchase minutes quota.

C

This is I've totally hand waived. This method um at like I'll, make my text a little bit bigger here. um This is the current way we determine if you have minutes left like for.com, um so for self-managed customers, where there is no um well there's no concept of plan, there's no monthly purchase minutes that will just that won't exist, and so we'll ignore it. We'll select the minimum of this one value and it'll be that value.

C

But if this exists, if there are purchase minutes, we will take the lower of the two so for us running, gitlab SAS. This will always show up and we'll always take the lower of the two Drupal I. Don't think we'll ever have this be a value, but as an application, we need to compare what we select kinds of limits.

C

And take the lowest one just it's to make it universally functional.

E

That makes sense cool.

C

um There's a few particulars that I'll cover quickly before, uh if I stop for question.

D

C

Sorry, at least not for questions about that. Any um any questions about this bad boy before I move on to where to where some of these settings are gonna live.

E

I, don't know that I have a specific implementation questions. I know Anatoly has been doing most of the sort of initial Mr implementation stuff, so he'll probably have the details about taking it from sort of uh code sketch to functional, um but um overall uh I do think it, uh as I said before. I think it meets the use case that we're talking about and then yes, I totally think it you know making it generic so that we can continue to follow right.

E

We don't we don't want to be um hacking gitlab for our special use case, so making them making sure they're generic Solutions so that we're using this as a kind of off-the-shelf feature that stays caught up with everything you're doing is is an important part of making this work so yeah, but yeah yeah.

C

No great and honestly I think this is going to be great for um for SAS configurability too.

D

C

You know we have. We have folks with some sprawling uh organizations on SAS. That I think would appreciate some of this control when they, what like you know the greater your minutes purchasing the more you might be interested in this, so I'm I I think it's going to work for everyone.

A

Hey Drew: does this apply to all Rudder types, or is this just shared Runners then.

C

uh That is an implementation detail of this huge hand, wave that I did down here. Okay,.

A

So it would follow the same logic. That's built in there.

C

C

The plan here assumes that that question is already answered somewhere else in the application. Okay, um if the part of the strategy about deciding about doing this comparison as close to your pipeline and build it like in the project not doing a calculation at the namespace um is that we can get very granular in here. In this logic um and say like: does this project have minutes what sort of Runners are assigned to this project? Does it have speci?

C

Are there tags for its builds like we could ask those sorts of questions and handle it in here? um This is this stuff up. Here is purely a number of minutes calculation, um if there's Runner specific things, that's either in here, and we built it somewhere else or no. It's not part of this plan up here.

A

This is the all of the quarter logic as it exists today when it comes to license works on shared staff. Runners there's also group runners or project Runners and I want to make sure that either we're staying out loud.

A

This is only going to apply to the shared Runners on a self-managed instance, group Runners and project Runners were still used, whatever they used without being able to set the limits on them, um or we carve out that use case and say, and here's how we're going to handle for the group Runner situation at least, and so I want to I mean really that's a question for Tim, and- um and it's only uh is that a use case that we need to cover here is that a use case that we could handle later primarily you're focused on that shared Runner use case.

E

um I mean speaking for us right now, yes, I think primarily that's you know we are. We are managing Runners at large, as as shared Runners for our in for our sort of whole instance um uh for our community, and so that is really the use case. We would need to solve. I do think that in terms of making this a long-term generic solution, you're right, it does make sense to think about whether there's configurability on a runner type basis or something like that.

E

But but for now I would say yeah focus in on on the shared Runner case, perfect.

A

I love, reducing scope.

C

So some something something will get somebody from Runner Fleet Management in here they can. They can figure that out later.

F

Yeah um I get I got questions why we need default per project limit if, uh for example, for Drupal case I, believe we can configure it on on the namespace level like the default limit and that default limit will be like for for all the projects.

F

C

uh You're talking about this limit here, yeah, um this limit is configured at the namespace level, which is a group or a subgroup. It can be anywhere.

E

um So, for example, this would be in the Drupal case when we have all of our projects right now in a single namespace, for partly because of permissions inheritance and partly because of historical reasons for how it defines the git repo URLs, that are the endpoints that people use and that.

C

Was a fun read, yeah.

E

Right makes things complicated when we're a 22 year old project and we're trying not to break anything that might be out there, but anyway, um the idea here, I think Anatolia. If I. If I'm interpreting your question right is we set one namespace soft default as it were, which is the like. Okay, any project, we don't specify of these 30 000 projects and any new project that gets added to the same namespace defaults to a limit of 400 minutes a month.

E

But if we go in and find all of our projects that qualify as Drupal core projects or Drupal strategic initiative projects, where we're deliberately saying we're going to invest more in those projects, spend more money on our Runners and all those things, then those get separate hard limits that that override the default, but don't force us to change the the um that don't force us to change any other defaults and then, at the same time that functionality doesn't break sites that do enforce a paid quota.

F

All right, so the logic here is that with a specified defaults and then overwrite the the defaults with custom limits um and to implement that in uh in a different framework where we have like limits in everything, we need to have this default as I ever write. Yeah.

C

F

I I would better like I would prefer that, like overwrite uh settings uh like explicit, overrides uh limits override for projects.

B

Because that is, that is what's happening, so the hard limit overwrites the default.

C

Right so the essentially the the difference here is that the default per project limit can be overridden by a higher number.

F

Yeah is it possible to name the variable like overwrite like Ci minutes limit overwrite.

C

Yes, I am not attached to any of the names in this merge request. Yeah.

F

Because, for me, hard limit is something that you cannot like uh cannot grow more than like anything else. So the idea, that's hard limit can be greater, is kind of alien to me. uh So.

C

So let me run through this again, because I think I think we're might not have I think we might be swapping the functionalities here. The hard limit is.

C

At any, like no matter how many groups and subgroups you have, if any, if a top level namespace subgroup sub subgroup, sets a hard limit, nothing under that in the high in the organization tree can go above that limit so like that that'll exist, I, don't think! That's mostly what Drupal.

E

Wants to use, we won't use that particular one, but other people in our use case that will be unset for most for for our namespaces and projects, so that'll be that'll, have no value, which is what allows the next variable or the next limit to or function two right to use its default.

C

So this this will be your 400 minute limit that it exists in the absence of any other configured limit.

E

And for most of our special projects, our Drupal core, our strategic initiative projects, it's the line, 41 explicit CI limits that we will have set, but in our particular use case, we'll almost never set a namespace one.

C

So if the default per project limit was set to 400, you could set this to 10 000 for one project and that one project would get ten thousand. If you set this to 400, you could not this. You could set this to 10 000. It wouldn't matter like if this is set to 400 the limit's going to be 400.

F

E

Have to we'll have to finesse the naming to help make that readable, but but I think these.

C

Are um I think visibly Hasty, please yeah.

F

Yeah I think the the the the limit hierarchy is clear so that, on the top level you, if you set the limits it will set the the upper uh bonds for all the lower limits. So I just expected something like just just limits like namespace limits, project limit and that's it and then these defaults per project is would be limit overwrite or per project like overwrite. That would make.

D

F

Easier for me, but it's not the logic here.

C

I think it's just the reverse. This would apply everywhere and is overrideable by this.

G

Yeah I think if we were like just to abstract those variables like into us in a normal variable, it'd probably make a lot more sense.

F

So there is also the namespace I was thinking the namespace instance level. I was thinking that there should be instance, level as well, that specifies defaults for uh like project limits uh and then, if you have to extend that for specific projects, you you set a different uh overwrite value that is not dependent on anything at all, but yeah, okay, so um it will be easier to have those cases listed and then how to these variables match these cases like see these settings in in the table. Maybe.

C

Yeah so I I think this. We could do it at the instance level and we might use plan default. We have plan default, ion limits, um Ford, Drupal I, think because you have that one top level namespace called project setting this to 400 for the project namespace will be functionally equivalent to setting it. For your whole instance,.

E

Yeah in our particular use case, that'll that will function in the same way. um Okay, great it'll, give us the purpose we need and- and we have strictly speaking right now- we do have two top levels. We have a projects and we do have a like Community Fork shoe Fork level, but that's easy enough. That's only two namespaces to worry about that's yeah, not not compared to trying to individually worry about the configuration on thirty thousand projects. Yeah.

A

Hey Drew: do you think you could um pull up the Epic and that diagram and we can see how these fit in there.

C

A

Here's the direct link to the diagram, the zoom.

C

Chat in the zoom chat. Thank you kindly.

B

I, do wonder, will it also help to go through the other chunk of code to like see where those variables are set.

C

Yeah my next piece was: you know what I'll have them up in separate tabs with the chart? I'll go back and forth through the schema stuff. That'll be that'll work.

C

C

So let me push some of my own stuff around here right, so the this is a that's quota right, so instance. Admin setting a quota here is like this. Is somebody at gitlab setting this for gitlab.com right. This is that, for the whole instance level, you know we say that ultimate gets 50, 000 or whatever. It is now important.

E

Keywords to track here are quota and limit. Yes,.

C

I I have a spent a lot of time. Reading about the words quote in lemon fair enough, um so everywhere that we use the word quota here, we're using, which I think is very helpful. We're calling it a license quota might actually change this to say: license quota as well um with the idea being a quota is something that you've purchased and can use up. It is your purchase, so it when we talk about this for gitlab SAS, we think of it, as you are purchasing a portion of the available compute.

E

So quota equals purchased, limit equals configuration option. Yes,.

C

um So that's when we get down to the the limits that we're saying there can be configured at the namespace level like here and they'll, they'll, inherit down to its own to projects and subgroups and then at each project level when any given pipeline is running, we just say hey project: what's our limit and the project can inherit the the project can be any one of these inherited things. It can be its own project limit and it could be the namespace limit.

C

It could be an inherited namespace limit or it could be the license quota and that big lisp looking block of code that I had in there uh chooses between these three things.

C

um Let me switch back over to talk about some of these columns.

C

um We're planning on having.

C

Project limits, like an explicit project limit for one project, is pretty straightforward, um that is a column on Project CI CD setting and the one that lives on Project CI CD setting is a really straightforward limit.

C

um When a project wants to know what its limit is, we just say: did somebody give this project directly a limit, and is it less than the one that the namespace says we get take whatever the smallest one is so this is just an an integer it'll sit here and then get compared here. That's the whole thing. The the fun starts when we're doing the inheritable hard limit which lives as a namespace CI CD setting.

C

um So it is configured at the level of a name. So this could be a group subgroup top level namespace, any one that they all chained together um and for any given namespace we see if it has, uh it could check its own column, value simple, integer, just kind of like the one in the project, CI CD settings.

C

But if the namespace has a parent name space, then we compare our column here to the parents and select whichever one is smaller.

C

So this is still in the in the hard limit world, where every group in a higher every group in a hierarchy chain can have a can configure its own limit. But whenever a project asks what the limit is, it will ask and it'll get the smallest limit available. Does that make sense.

F

Yeah, but um why I I think it will be like several database queries to get those values for each of the namespace and, if I believe that's n, plus one problem or something I was reading the last week.

F

um Is it possible to just extract all those um you know hierarchical limits in one query and then just select minimum from that.

C

It's certainly possible um I left a note in here um about talking to the database people when we're building this. um We have some practical limits on namespace depth. I can't pull them up in front of us right now, but like people, don't have 1500 nested name spaces like deep.

C

um There is a practical limit on that, so your n plus one might get to like three or four I think um and so having a practical limit on the number of queries that can actually happen and there's a judgment call to make around.

C

Do we want to make three or four very simple queries, or do we want to make one more complex query and that will depend a lot on like the query plan, you know we'll see what performs better, what our plans are for scaling and make that decision at the time in the Mr.

C

For the purposes of the this was the simplest way to like explain it. So I wrote it this way.

F

Yeah I just uh thought that in rails there should be some kind of uh construct for fetching those hierarchical settings, because basically every setting in gitlab is hierarchical. Yeah.

C

We have tooling for that, um if we I would use it when we need it um and I just don't know yet. I was writing up this draft this week and Caroline and I said that this seems like clear about the business logic, which is really what this draft here is demonstrating.

C

um So as long as we have that I'm perfectly open to whatever query seems to perform better, that's a that's. If that's a yeah great thing to call out because it could, it could go either way and I do not have any opinion. Yet.

F

Okay, so it's prototyping got it. Yes,.

C

Yeah for sure um right, which is you know why you know I named stuff like this, um so that's the anyway. So this is the currently recursive kind of simple look up: The Chain Grab, the smallest answer and come back implementation of that hard limit.

D

C

We always take the lowest value. We see no project under that value can never go over. That's the end of it. um The inheritable default that can be overridden by a higher value is a little bit more interesting, yeah sure interesting.

C

um This we have tooling for cascading namespace attributes.

C

We have a whole like meta, programmed uh module about this, where you can set a value somewhere in a namespace hierarchy, and you can lock that value and it becomes the oh and it be. Everything below will use. That figure.

C

um I again put a note here that I'm not sure if we can move this directly into um into namespace CI CD setting and have it work exactly the way it currently does in namespace setting, which is a similar like configuration model.

C

um Just we have our own for CI, because there's a lot of CI stuff, um so the, whereas, with the hard limit we will always Traverse the namespace hierarchy tree all the way up to the root and then take the smallest number.

C

um With a cascading attribute, we Traverse until we get a number any number and then we say that must be it, um and then we return there's a lot built into here. We can poke around in that later I I'm, probably beyond the scope of this call, um but the the key difference is that we don't do any comparison of the values we just say: oh we've gone up the tree and we found the setting that's closest to us in this project. So that's what it is.

C

um The Drupal top level project namespace could set this to 400 and everybody gets their default to 400 because we haven't specified otherwise, and then there could be a subgroup of a thousand projects under that project, top level namespace and you could still say well. The default in here is going to be a thousand like these is some special group of projects we're going to give them a higher to fall and those projects will get a thousand the proximity of the setting to the project.

C

Sorry, the proximity of yes, the proximity of the project to the setting is what determines which setting we use. It just goes and it gets the closest one, not necessarily the greatest or least one.

C

So that's what will make the 400 overwriteable for some specific projects? Is that like we? Don't we don't look for this until we see that we don't have this.

C

But all of this, both of these um limits are configured at the namespace level, so they'll be configured once and they do apply in their own particular logic to everything under that namespace.

C

E

I think it follows: um that's making sense I mean to anatoly's point earlier right, we're in we're in sort of prototype phase, but but that makes it clear and readable. So that's helpful.

C

Yeah yeah: no, this is uh very much uh demonstrating our way out of the business logic problem. This is the I. Don't expect this particular merge request to be picked up.

F

Is it possible to say on which level the limit is uh set both for default and for hard limits, because for debugging purposes, when something like goes wrong and limits like your minutes are over, you probably want to know which limit trigger. It is yeah.

C

um Yeah we talked about this. The there's nothing here in this, uh this draft that details that all we're doing is passing around integers um but I, think and uh vedica I'm, not sure if we have designs or anything for this, yet we haven't talked about it.

C

um A note that says you've hit a limit set by this person, or you know at this group level, um makes a lot of sense to me. So it'll be it'll be traceable. You know we can hopefully link to places where the limit is. So, if you know, or at least tell you, you have to contact somebody from this Group contact and owner of this group to change your uh to change your settings.

F

C

D

F

D

Sorry um I just wanted to mention that I think there is a banner in place. I'll quickly go and check and post here.

B

The the plan was to have it out of scope for the MVC to have the like the UI to display what um value was causing you to hit your limit, but that that would be a follow-up um issue to add that um for the Drupal case, it will hopefully be fairly obvious. Since you only have like two levels um at this point um but yeah once you get like subgroups and things it'll be much more confusing as to where the the limit is being hit.

F

Oh yeah I'm, not thinking about UI, but I, think that if there is a detection of that level here in the code, there will be comments with the specifying which limit is hit. It will make quad more like readable or with with because the error message would need to specify what is the exact uh condition here. Is there like something not set, and then something sets and overridden like the tricky stuff like this, so.

C

At at like check run time, there's no reason when we pass back one of these integers, we can't pass back the full path of the namespace to say: hey, here's where it is so that's that's easy enough to do. It doesn't really require any extra querying or heavy lifting. We already have the records available um and we could also um bundle some of this stuff up that. Oh you know this is just in setting. We could probably use it from right here. The way this is written, I, don't think.

C

We'd have much trouble, just demonstrating an entire limit hierarchy as a view like we query the whole hierarchy to and then pick which limit is lower.

C

I, don't see a reason why, on a project, CI CD settings page, we couldn't query the whole hierarchy and say Here's all this. Here's everything that you're subject to here's. You set a limit in your little subgroup of 10 000, but the group above you has it set to a thousand. So your limit's not going to matter like we can we there's this high. This design is amenable to that for sure.

F

Yeah, because uh in the past they used those hierarchical interfaces for setting authorization, rights and I believe that will be really useful for understanding how it's set.

G

A

Anybody watching later there's some chat happening, um I, think uh or Peyton says that uh I think docs will agree or help here. I agree, I, think that the error that shows up today when you're out of minutes appears in the job, log and so boring solution might be to after we, you run out of minutes and the job can't start um to dump out the limits there um and we think there's some errors on Pipeline creation as well.

A

If a pipeline couldn't be created at all, there might be some Banner alerts happening in the UI, but we're working to confirm that now.

C

Foreign yeah hooking into our existing, like Ci failure messaging, might be low effort and unsurprising to people using our.

G

Ci and we might not even have to like make it an MVC like so we don't get into the UI, because I would say most of those error. Messages are generated from the back end anyways. So it could just be. You know dynamically updated right.

A

C

A

15 minutes left I wanted to make sure that we had time for any questions from the wider Community about specific Mrs, to dig into anything and and get some synchronous time with those folks uh in the last 15 minutes. Here.

A

If not I'll, let Drew keep talking and.

C

That's how much feel.

E

It yeah um I'll, say I, don't have specific questions on the implementation stuff I do I might have to drop as questions are are going on specifically so I'll just really quickly say: I want to thank Anatoly in particular for doing a lot of work to do a bunch of initial Mrs and actually kind of get the ball rolling and then a thanks to everyone on the gitlab side, James Drew, Caroline, Peyton others who have um just kind of made it possible to figure out how to do this kind of contribution.

E

um It's been like it's kind of been a test case for understanding it for a community, the size of drupals and and how we can make an improvement on this level, and so yeah just wanted to say that I really appreciate that I appreciate and it's all these uh efforts. uh Quite a bit and I appreciate the concept of these um uh office hours for this sort of conversation. I think this has been good, so.

A

They don't within gitlab, there's some other groups who are doing monthly. um That was going to be one of my follow-up questions was. Is it valuable should we continue to do this um as a product group uh and just make this a regular Meetup and we can ship times around as well uh pretty from time zone coverage should not be the same time. Every month.

E

Yeah I mean I certainly found this one valuable um I, don't know you know, maybe the pacing I'm not sure, if there's enough activity to guarantee that every month has has something new to to say, but in this case where it's like: hey, you've, internally kind of re-sketched out or re-prototyped the business logic and there's that gives us meat on the bones to talk about like then, then this sort of makes a lot of sense, um a good place way to get on the same page. At least that's my two cents.

E

But um someone like Anatoly is doing a lot more brass tax work with actual Mr stuff. So you may have different feedback.

F

Well, I'm just waiting for decisions, so I don't do anything right now, so I'm waiting for the design to come.

A

All right, well, well, um I think we can make these monthly uh moving forward because we have other topics outside of CM minutes um that we could definitely talk about or review at Mars with folks um who are looking to contribute um in other areas of the product. uh But, let's Circle back to then to Anatolia.

A

Since you have Mrs and you're waiting on decisions, can um we hand over to Green sharing to you maybe to talk through some of your specific questions or where you need guidance um to move things forward so that you're not stuck or waiting um on the gitlab team.

F

Well, uh there is a just as simple Mr: it just adds projects uh limits, setting and that's it so I mean once the decision is made. I will look forward how to add some logic to that and how to check that and all the things would follow so for now. I just need to understand the the whole logic behind it and basically like make it unblocked merged and then move on.

E

Do you have that link handy Anatoly? Could you put it in the chat.

F

Yeah we'll do right now.

A

I think it's the one that we were chatting in earlier this morning or my morning, Anatoly um I, just shared it in the zoom chat.

F

So yeah it was my first uh Mr to the GitHub I believe so I got into some refactoring of the tests and into the depths of of Ruby code for the testing, so it might be not trivial to review. Maybe I should move that part somewhere.

F

That's about delegation um of settings, so I made a new piece of code that checks actual delegation because in rails there is no mechanism to check if the method is delegated and made by my own.

F

So that's could make its review harder.

G

A

You took an initial look at this back in November and we were waiting on some decisions, I think that might be made, and the Mr that you have to sketch those out um today at how the limits work would apply here.

A

um I think that this would need to be reworked a little bit to use those Concepts, and then we can move it forward.

C

C

F

Go ahead, yeah I mean the naming the the placement of the settings and uh for for, like my initial, and we see it should be like just a project setting and then in Drupal. You kind of can get the script and set this um limits for all projects, just one-time way without UI, but that won't be like the long-term solution. For you know, administrators and and the people so uh like the the Mr is not is simple, but the decision how to properly integrate it is. It's probably not.

C

E

It sounds like possibly a and I don't know. What's already there, I'm I'm only just re-looking at the Mr, but it sounds like possibly another comment round from from Drew or Caroline on the existing Mr to integrate it with the sort of prototype sketch that we just saw today might help give that direction. Yeah.

C

um I think this this makes sense as the um the direct and explicit project limit. um I'm gonna have to look at this again and dig into the delegation code and make sure I understand what we're doing there and I can I can write back on the Mr about that.

F

Yeah the delegation code is hard because it checks the source for the method and if the source is basically starts with delegates, that means the the method is delegated, but not all ruby objects have source. So sometimes this this uh code will just fail, and that just happens right now, like Ci tests, don't pass because somebody added the property that that fails, foreign.

A

B

That isn't actually like 100 necessary for the setting. It might make sense to like separate that out into a separate Mr.

C

B

So that to separate the concerns there so that we aren't uh mixing.

F

Yeah I can try to do this, but because uh that touched the tests, um probably the delegation- needs to be merged. First, okay,.

G

B

A

Also, since, like next steps, there are new Mr just for the delegation part and then true, you can add comments, All right so and I told you. Will you open that new Mr and pick that part out of this one? And we can reuse this here? You can comment back with the sketched out Mr how to work in those new limit. Concepts.

F

Yeah, you can I can do this yeah, but should I open a new Mr for this setting, because there are like a lot of comments already and comments, so I can split it in two Mrs and close this one yeah.

C

I think I think that'd be helpful while, while I have you right here, can you give me a just a quick what this delegation tell me if I'm on the right path here, the delegation means that, when says when cicd settings is destroyed, um the delegation function here is to make sure that the limit code remains functional. If the settings record gets destroyed,.

F

um It's more as I understand about Ruby moving like rails moving those properties to separate namespace, so the CI CD settings are not in Project. They are in project.cicd settings. Yes, so um when you destroy this namespace like with cicd settings and somebody tries to access.

F

Those properties in in in in projects which were delegated to to this project to to these CI cities namespace those will return nil, so right, okay and and for- and that was like hard code at least, and it didn't really check the delegation. So you have to put your methods in there manually and manually check them. So when I I wrote this method and it immediately caught two errors in these lists, so I decided, that's I should go this way.

C

Okay, um yeah, then I think definitely, let's split them out, because I understand the attribute stuff perfectly well and it all looks great and I'm gonna I'm gonna check out our delegation stuff because it sounds like we might be testing something in a not obvious way um and I think that's a worthwhile separate discussion to have about how we manage that.

F

Okay, so I'll try to do this tomorrow: okay, I buy tomorrow.

C

Thanks and uh feel free to ping me under.

A

A

Definitely thanks Drew all right. Well, we're sneaking up on the end of time. I want to make sure everybody can get to their next thing. If you have something scheduled at the top of the hour.

E

Awesome: okay! Well thanks! Everybody I really appreciate the time and the invites to this event and James in particular thanks for organizing us and getting us together for this. Yes,.

A

I'm excited that we got folks here to talk. uh This has been good, uh definitely energizing and we'll keep it moving forward.

A

um So I'll share the notes um back into all the places uh and I'll post it on our unfiltered Channel as well, um so that the The Wider Community can be it and keep up with how we're progressing on this Epic.

E

Awesome. Thank you. Everyone all.

A

Right thanks, everyone cheers.