GitLab Verify Group, 31 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Verify sync meeting on `interruptible` CI YAML keyword

Description

Engineers from Verify teams discuss issues https://gitlab.com/gitlab-org/gitlab/-/issues/23605 and https://gitlab.com/gitlab-org/gitlab/-/issues/412473 to find a common use of the `interruptible` keyword when auto-canceling pipelines.

A

Hey everyone. uh So this is like a sync meeting on discussing the interruptible keyword for CI configurations, and we want to evaluate two different issues that we currently have that somehow might be related to using interruptible um keyword and and yeah. I would like to discuss like what it would be, um the role of interruptible, and how can this fit into the auto consolation of Pipeline and also related to a new issue where we would like to fail a pipeline fast and which seems to be a sort of Auto cancellation.

A

And how can you know this all fit together and try to understand responsibilities there, and so we can look into the future of interruptible as a keyword.

A

um So we have these two issues.

A

They fail pipeline immediately.

A

Let me share his screen actually.

B

The agenda is on the calendar by the way you're not on it.

A

Thank you, uh nice. So uh what is issues is this and which is?

A

We would like to fail pipeline immediately as soon as a job fails um and another issue related seems to be based on the current evolution of the discussion would be this one and which is that we want to be able to allow users to control to have more control over when and how to or cancel Downstream pipelines, and initially this sounds more like a bug, but in reality it's more like expected Behavior, because we, the interruptible, even if you set a job as interpretable. True it doesn't mean it will never be encrypted.

A

It can be interrupted as long as it's not running. So if it's not running, we can interrupt it. Otherwise, it's just like not not touched, and so this is actually uh the interruptible true is potentially interruptible or or likely interruptible. So I think it's like it is like a definition there there's like a little bit there ambiguous, and this is probably why we had this issue in the first place. Sorry Drew, let's say something: yeah.

C

Yeah, the um the current definition is I in the make sure I'm right before we can start this. The current definition is more like the pipeline is allowed to remain interruptible after this job has started less so than this job itself is interruptible.

B

I'm not sure I could.

A

So if this job.

C

The way we the way we use interruptible like programmatically, is when we attempt to cancel the whole pipeline and we check have any not interruptible jobs started yet like, even if it's like earlier in the pipeline, and it's run. We just say that the pipeline is not interruptible, because that past job had interruptible false.

C

um It's like we use it to sort of like set a like a to just set a point in the execution of the whole pipeline to say, like interruptability, is over now going forward.

C

So I think the the difference in because we can figure it at.

A

The job level interpretability will be calculated on a very specific moment in time right. So if we check the pipeline and there's some jobs that are non-interruptible, but they are in an appendix state or you know enqueued, then we can still cancel the pipeline right. But if and that's very specific moment that non-interruptible job is actually running, then we say we can't run. We can't terminate this pipeline.

C

Or if that job is finished,.

A

Yeah, if the job is finished,.

C

As soon as as soon as that job starts the rest of the entire pipelines execution, all the jobs we say is no longer interruptible.

B

This is the only case. This is the case that, when jobs have interruptible faults by default right, not the other choirs so I mean. Can we just summarize this? Okay, we have two-way. First, we ignored interruptible, true or false. If a pipeline has jobs that just pending never run so we can just cancel the pipeline. Auto cancel the pipeline, we don't care about interruptible, true or false right. That's.

C

B

First case, actually, because.

C

They've never started yeah.

B

C

B

Second case, uh if a job has interruptible, true and and auto cancellation is firing, so we don't care about the other jobs we just can Auto cancel the interruptible through jobs, so that's the two conditions that we ought to cancel jobs right.

C

Will we cancel other jobs.

C

B

The jobs that have interruptable through.

C

Right right, that's what I mean if there's one job with interruptible false, we'll still cancel the other jobs that stay interruptable. True, I,.

B

Think so that's why they're interruptable through.

C

A

So, are we talking about Auto, canceling, redundant Pipelines, so for automatically written pipelines we cancel a pipeline in all the jobs are non-interruptible.

A

B

And we're waiting.

A

Yes, well means meaning that not.

B

Picked up by Runners.

A

Yes, they've not picked up by one yes, yeah uh all can be completed like in that case right so yeah. We kind of um I think we have a live. We can double check actually.

A

Make some space here.

A

A

C

So yeah Auto cancel interruptible pipelines, yeah.

B

With only interruptible builds I, that's the scope.

C

Yes, and that scope is.

B

As a weird SQL conditions, there.

C

Yeah, it's a not exists, any started, interruptible jobs. So as soon as one interruptible false job has started. The whole pipeline is not cancelable anymore, correct, right.

A

A

Oh because we have started statuses, yes, so even the cons. Okay from the point from the moment, the job transitioned into running we okay. So that's.

C

Yeah uh running success and failed. Yes,.

A

C

Yeah, so it's like a it's like a flag as soon as there's one that starts running. That pipeline will always not be interruptible. Yes,.

A

So this would be then, uh so we have basically this proposal here um about giving a little bit more control over the use of um so actually here over the use of Auto consolation. So we can for now we're going to focus on the uh canceling within the pipeline. So it seems like the current way today.

A

Is the I call it the conservative approach, which is like okay as soon as the job any of the job is, has been running, that is non-interruptable, and then we basically are conservative, and we just don't allow this pipeline to be canceled, but there could be other um more other kind of um settings for this kind of cancellation. uh One would be like if you want to completely disable cancellation under certain condition. It could be for a specific child, Pipeline and a another.

A

One will be just interrupt, anything that is interruptable and leave, and basically, if a job that is not interruptable has already started just let it continue, but anything else you can cancel it.

A

um So this is, if you want to aggressively, save on on compute minutes, for example, and then all is like to force basically canceling everything. um If this is something we would like to do it or or maybe you can even avoid that it.

B

Will be just clicking the cancel button on the pipeline right, yeah.

A

It was the same as canceling yes yeah, um and so so this will be like a way of kind of managing a little bit more um control.

B

A

Because some users might want to um allow certain pipelines to always run and basically forget about um interruptible, um which is the case of okay, even if I said something, that's not interruptable, but it can potentially be canceled if the job hasn't started running so instead, I want that auto consolation never runs on specific pipelines uh so yeah. This kind of a this is like a proposal myself, a problem.

A

So go to the other problem of failing a pipeline fast. um So we have this other issue where which is like if a single job fails we'll do like to terminate the whole pipeline.

A

um So one idea there seems to be that we we just use the fact that one job fails. So it's gonna affect any way the pipeline in a failed state, and we can cancel everything else right so rather than failing, for example, the rest of the job. So we can cancel them and so there's a distinction between which one actually failed versus which one were automatically canceled um nowaday.

A

The debate seems to be more about. Should we use or not droptable in this case, or should we use interpreter interruptible the same way we've been doing with oral ventilation or instead and employ like a configurable value like this um Audi I would like to hear like two thoughts on that.

C

um My instinct.

A

C

That interruptible is that I don't want to use interruptible to describe any of these things, because it's we already use it in an open-ended way, and so it's like.

C

It's it to configure to assign new functionality to the word. Interruptible feels like we're overloading a term. That's already misunderstood,.

C

And I'm worried that worry isn't like entirely specific yet, but it's more it's just a sort of. If we do this people are going to some people will expect what the change we're making and some people won't, because currently I think people have different ideas about what interruptible means.

A

I I share that sentiment, uh and this is this is why I think introducing something more explicit like okay on new pipeline, conservative or okay. It makes it more explicit that how are we using this interruptible? uh Even if we, even if it's like you, know, conservative or disabled, for example, like we have no other kind of a fine way of fine-tuning? This I think it's still an improvement, because it makes it clear how this works. Yeah.

C

Yeah I think um I think using the word cancel makes a lot of sense because we like that's that already exists and is very explicit like for Ken was saying like it's, you know, cancel all would be like clicking the cancel button that exists and because it says, cancel when you hover over that button. Now we could stick with cancel and just be like yep.

C

It cancels that and this so Auto cancel redundant pipelines is like a really specific kind of cancellation, and we could still do that because they, because that is interruptible- refers to Auto, canceling, redundant pipelines and that's a very specific workflow, but this could be on any other kind of Auto cancel and so, but because it's not the specific redundant pipelines, workflow I think if we stay away from our interoperable we're good um I'm trying to think the the thing that I think we'd have to add would be some kind of like cancelable configuration to jobs themselves.

C

To say like this job like while running, can't be canceled. You know I mean you know if it's some kind of deployment thing we're saying we're bringing up new infrastructure in this job. You can't stop running this job.

A

That's the purpose of interruptible right.

C

And well, no, it's I'm saying that in a way that it could cancel the rest of the pipeline, but let this running job keep running right. If, um right now, if you have jobs a b and c marking b, interruptible means you can only cancel during job a as soon as B starts. B and C are both on interruptible, false yeah.

A

C

As as it works today, right right, yeah exactly so.

A

This is like, if you, if you would have like a default and conservative on Pipeline, not a new pipeline. You have this default thing. So, let's say: okay, you can make a a non-interruptible b and then C will never be canceled.

C

Yeah yeah exactly and so introducing um the idea of well. We can't cancel B because it's running, but let's cancel job C, that's still pending that's cancelable and then the pipeline will just be done when B finishes I think that needs a new term.

B

uh So I have a question so without thinking without thinking about thinking about this issue. This uh Auto cancel uh issue without thinking about this. For this, let's focus on this pipeline fail the pipeline immediately, one edge up fails. So what do we have today for this I mean what is the proposed, but there is there any proposal that today that but independent from this, this Auto canceling. So what do we have?

B

Do we have a project settings, for example, project settings? Any project settings enabled okay. If a job fails, then all pipeline fails or do we have a CIA mode, config? Okay, this one.

C

A

C

A proposal I don't think we have that functionality today, existing.

C

A

I wrong yeah. The proposal will be what we have so.

C

Far is to introduce.

A

This cancel and job failure: oh yeah, okay,.

C

Yeah. Because, because that that's like I, think one of the the common like uh common needs from this functionality, yeah.

A

Because people just want.

C

To stop running faster, but.

A

This is to be equivalent to to um doing.

B

A

On job failure by using all right.

B

C

Which is like a it's equivalent of.

A

Click in the bottom like force, canceling everything, maybe.

B

Maybe we should just start with that: I mean, as Drew said. Maybe it is not uh it. It is not needed right now. Auto cancel and interruptible mixing game together. Maybe it's not needed today. Maybe we only need Auto cancel on job failure. All that's all we need today.

A

Yes, it's true, um but if there is a way we could um join the two things together as something they're actually similar in nature. If, if these are similar in nature, maybe they could, you know behave similarly, because the back end could be similar it. What it would change is like um the trigger you know. One is when a job fails, another one is when a new pipeline is created and then you go in and search, but the side effect. If the side effect is the same, then, let's like let's try to explore this.

A

Are these same side effects? So this is the best one. We ever need to try to confirm and canceling a pipeline so from in my opinion, when we want to cancel a pipeline fast, uh is equivalent to design to consolation and, in my opinion, is not like equivalent to clicking the button cancel um because of because of the reason interruptible was introduced in the first place, so we wanted to some people to say. Okay, this job is critical.

A

Whatever in the pipeline, you put it, we shouldn't, cancel it right, um but now it's like If You by using something like all. It makes basically interruptible like useless uh in a way because say: okay, if I have a deployment that I said it's an interruptible, but for some reason there is something that is that fails.

A

um Then they interrupt. Then the actual deployment is canceled Midway. And now it's it's on me to try to understand the topology of the pipeline, where this interruptible and uninterruptible jobs are because I need to be very careful about this right where I could see failures, but I wouldn't see that right. So this kind of conceptually, you know, makes it hard for authors to really understand kind of a manage.

A

The background in this way where you might want instead to say I, know about this job, but this job shouldn't be interrupted, so make the algorithm work in a way that it will never kind of um interrupt this job and I think maybe digressing a little bit but like I, think even the console button on the UI should be able to like cancel things.

A

You can cancel right, but if something is not interruptable give me a warning or something like, or you know or or give me the option to force cancel everything right if I want to, but by default should be like a safe operation, uh but we don't have this today, so we actually, you know, that's why we say: okay since you're using canceling intentionally, then it's on you to figure out whether you can actually cancel it or not.

A

Okay, maybe this could be something we can implicitly say, but but if we are canceling the pipeline automatically for you, we then we should. We should use like a safer approach, and this is why it came in. In my opinion, the concept of interruptible is kind of interesting and maybe under Leverage, um so yeah. This is basically from my perspective, the importance that I give to interruptible.

B

um Do you think interruptible should be true by default.

A

It should have been interruptible by default, since we are anyway are treating canceling, basically yeah anything, so it should have been done by default. True, and then you could make it non-interruptible whenever you, you know explicitly. I think this should have been better, but now we live with this default and we need to try to work around it.

B

C

Interrupt sorry, interruptible is false by default. Yep, yes, I didn't realize that.

A

Yeah, if it was true by default, it would have made things a lot simpler and a lot more consistent. You know, because then you would say, cancel a pipeline. You know indiscriminately.

A

It would be equivalent with the default like and everything is interruptible, but that's not the case, and this is this is why we have this problem, which I think will be interesting too, also as an opportunity to fix uh all the inconsistencies within interruptible or make this emerge and try to understand. Okay, how can we maybe transform interruptible yeah and.

B

Should we maybe uh project settings that, in a makes this interruptible tool by default and for new projects? Yes, but for all projects? Yeah, it's optional.

A

B

Would it solve the confusion actually.

A

I'm not sure okay um I mean if, if we plan to flip the default and eventually you know it, remove a lot of these inconsistencies in the code. Yes, but like that will have like a large impact on end users and and having options.

A

C

A

C

um Yeah yeah, that's that's clever because, like we could do things like um like, if we want interruptible to refer to specific jobs and not all the subsequent jobs, that's something that would be a like. A big breaking change that'd be very hard to ship because we don't you know. People have referred to like everything later in their pipeline. If we ship the different definition of that with a project setting that's enabled by default, people can uncheck the box to opt into new Behavior.

A

But that could be possible with this syntax right. So if you use uh it's the conservative you use interruptible, then it will cancel the interruptible jobs living not available.

A

It would be also canceling non-interruptible jobs after the interruptible ones. So.

B

A

The non-interruptible ones.

C

But so imagine because that's the case right now right all the jobs after an uninterruptable job are also uninterruptable. Yes, in the current meaning yeah that project setting now we could write a project setting that is Default. True, that says, uh interruptible applies to all subsequent jobs, because it does so we ship that as a true setting, because it is true, but then it gives a customer the ability to uncheck that box and then suddenly we're in a place where interruptible is only that job itself.

C

You can cancel job C and just let interruptible un like interruptible false job. B finish, you know, gracefully or whatever, but still cancel subsequent work. We can let people sort of if we write a setting by default. We can let them change the behavior themselves by opting out of that thing that we just wrote. That was true that we Ship by default.

A

Yes, but that allows with the project settings kind of allows you to apply this Behavior to all Pipelines right.

C

A

It is better from like using local syntax is that you can actually say like actually the customer specified feedback down here. It's like um you know. If I'm using a protected Direct, then I want to disable or like a or like disable cancellation, but if I'm using the non-uh protected web, maybe I want to con use. Interruptible, uh like you know, cancel anything you can, or maybe it's you can instead of disabling here, you can use. uh You know if you're using something like you know, a branch where you deploy to production.

A

You might use a conservative approach, yeah and and a more aggressive approach on merger requests, pipelines for example. um So this is like the advantage of having something like this rather than project setting would be for everything. Maybe you want to have some settings for parent Pipeline and some other settings for child pipelines. You know yeah and that won't be possible to do it with the with the projects. Oh.

C

Right right right, so all that I think we could still do with the ammo configuration I'm saying what for can just suggested can let us change the meaning of the word interruptible in any given version, because interruptible means a really specific thing. It means like this pipe this job and all subsequent jobs.

C

But if we ship that as a denable as a default enabled setting, we can change that definition in any given version. Interruptible doesn't have to mean this job and all subsequent jobs.

A

But you can control this with this setting right, you don't need the project starting. You could control with either using conservative or interruptible.

C

Yeah right, but if you use the word, interruptible you're saying like to integrate these things. If we don't like the current definition of the.

A

Word interruptible as.

C

We use it, we can write a new definition and then just call what we currently do. Some special case. That's like oh yeah. If you have that setting enabled that's what it means, but you don't have to enable that setting it could mean something else. Mm-Hmm, it's a I mean that's also I mean we're in the middle of 16-3. So that's a to me I think that's a very clever idea about how to get how to move some of these changes before nine months. From now.

A

C

I, just it gives us I think that would buy us a lot of flexibility around the word. Interruptible yeah.

A

Okay, well let me let's, let's evaluate this- let's add this to the action items.

C

So yeah yeah, no, that that's um definitely not to not to replace the CI configuration but specifically to give us flexibility around interruptible to use it in different in a different way. In the CI configuration okay.

A

Yeah this the project, setting, though we need to consider that it would add, like another um kind of a level of uh or or controls the meaning of um interruptible, which means is like, if you have this setting enabled you know in interruptible, will behave this way. But if you have the setting in it like disabled or set differently, it would behaved differently. So we will have money to have like different strategies depending on the setting yeah, okay, so yeah. We need to consider that kind of complexity also.

B

In the action item, you're, writing can you complete the sentence and I I want to know I mean what's the today's meeting? Sorry, what's the today's meaning? What's the next meaning that we are aiming right now so in the action item you are writing.

A

Yeah, so the meaning today is that um it.

A

Does not cancel the jobs so.

A

So if you have something like an interruptible calls.

A

And doesn't allow.

A

To cancel the subsequent jobs.

B

This is today's Behavior.

A

This is how yeah uh Auto canceling on redundant pipeline works.

B

A

B

Phones by default already.

A

And this is interruptible false.

B

Yes, by default.

A

B

A

And the other setting would be I'm assuming uh like, if you know disabling it or enabling it will toggle, basically the opposite, which is.

A

Cancels uh so see current event and jobs, okay, so this is like my understanding, I, don't know you do a correct me if I, if this is correct and.

A

Whether this is like, because I'm suggesting to use a yam of syntax without using preservative or interruptible, in my in my based on my understanding but you're, saying like if we use this project setting, it would have all the kind of advantages right.

A

B

uh I mean I, I, didn't know the effect of the subsequent jobs before this meeting. So that's why I don't have anything to say about it so, um but but I I get confused that okay, the this new feature, this project settings will change something for subsequent jobs. That's what I didn't understand. Actually what I'm on the meant was: okay, interruptible Force by default today, let's make it interruptable true by default. Yes,.

A

B

Didn't I don't know if if it affects the subsequence.

C

B

And I didn't understand this interruptible false cancels, subsequent jobs. I didn't understand the sentence actually.

C

I'm gonna leave that there, but let me write these the other way and see if it is a little bit clearer.

A

B

But its default Behavior already all jobs have interruptible thoughts. Yes, okay,.

C

In oh God, that's the thing that I learned today is that all jobs are interruptible solves by default. Yeah.

C

C

So for somebody to.

C

Mark so for somebody to use interruptible to Auto cancel the whole pipeline. They would have to go and put interruptible true on, like all the jobs until the end of the pipeline. That has to be configured explicitly today. Well,.

B

Default default interruptable to the right. We have.

C

This sure yeah yeah, true okay,.

C

So right, so, if we started with Default interruptible true, then you could configure an interruptible, true job that would run after an interruptible, false job. We could narrow the scope to.

A

C

Interruptible refer to only the job itself,.

A

Yes- and you could change it by using this setting. Yes, if you want look for for new pipeline.

A

So I I think the project setting might be interesting tool if we want to, for example, invert the default in the long term and where we say okay for new project. From a specific you know from 170, for example, any new project we will have interruptible True by default.

A

You can flip the setting if you want to keep the old Behavior, but maybe by 18.0 we're going to you know, always keep it default, Default, true and and you, if you want to use the old you just have to specify you know, default um in the yaml default. Interlock the ball uh false.

A

If you want to use the the old one, but that allows us that making everything by default interruptable it's more consistent with the cancellation we have today and an interruptible can be, can be used as like interpretable, false explicitly to indicate you know things.

A

We don't want to stop automatically and everything else is is stoppable automatically, and so maybe we could kind of consider this and the setting might be interesting to use that because it's there is it's a simpler logic, but you can use on setting and might be good to have it kind of across the entire project, and while each pipeline might want to treat the um the cancellation differently, you know, especially when we have parent child pipeline, the other cancellation would be very different from each other and for those who would make sense, I think to use yaml configuration.

A

uh Also, you know with rules no workflow and rules. We can swap the the strategy according to the needs, but then the projectile setting will be to control the default for the drop.

A

um So maybe in the future we could think into yeah um swapping the default and make it everything more consistent.

B

uh If I wrote something in the agenda, but it's not I will explain so so. Let's say we added this interruptible through by default project settings. It will actually change the behavior right, so we won't need to cancel the pipeline if it has non-started jobs within interruptible false. So right now we have this condition because interruptible force is default, but actually it shouldn't be. So that's why let's cancel the whole pipeline if none of the job has to Target. Yet we have this feature for specific. That reason.

B

So actually, if we have these project settings which enables interruptible through by default, we won't need this feature and also it will actually fix the current problem that we have in this issue. 41 24 73. So because this specific user don't want to cancel the whole pipeline and we will actually solve this problem and we will probably solve the other problems right. So we won't need to add any yaml settings.

B

If we had this.

A

Kind of use case that um I don't know, if maybe it's not part of the issue but like if you actually want to disable the other consolation and want to enable it or you want to use like a different strategy.

B

A

B

What you're saying they can they can do that with actually uh I mean maybe default settings with they can change it I mean Default job settings or specific job settings. For example, let's say this customer this uh specific customer, so they want uh interruptible false if commit traffic protected through I mean. Why would they need that? Because maybe some deployment, jobs or something like, but let's think about this I mean most of the time these deploy jobs is only in the pipeline with the rules with CI commitment protected tour.

B

Actually this would solve their problem already, but, okay, we are just assuming something. Maybe we will need to write this here in the issue and get feedback from the customers.

A

Okay, so um so swapping the default you're saying that might actually solve some of the customer issues.

B

Yeah, maybe all of them we don't know yet, but yeah.

C

C

Oh right, because it's you're not able to.

C

um Because there's a problem of like if the job hasn't even with Downstream pipelines like jobs, can it's possible for the jobs to not even be created, so they don't even have like a notion of interruptability yeah.

B

For the downstream pipeline issue, I mean the problem they have is that they cancel the pipeline, even if they don't have interruptible tour because of our feature.

C

A

Yeah but I'm not sure if this like it was still also solve the problem, because we are with the setting. We are swapping the default, but even if you said something as interruptible, true specifically, uh it doesn't mean that the downstream pipeline is never been canceled. It can still be canceled. The jobs are not running, which is the problem of this user of of this issue right, so the pipeline is still canceled, uh because no jobs are running so.

B

A

B

Wanted to cancel they.

A

Don't want to cancel so even if they set interruptible false the pipeline is still um is still canceled because the job hasn't started yet so it's maybe you can make a distinction a bit Unstoppable, it's like stoppable. If it's interruptible and yeah.

B

But but if we add this project settings we will remove that feature for okay. Let's also include the pipelines that have all jobs non-started with interruptible Force. We will also remove that feature.

A

Which features? Are it.

B

Okay, so so today, uh when a pipeline has all non-started jobs, even if they have interruptible false, it gets canceled right with this settings. We will remove that. We won't. We don't need that, so we don't we. We won't cancel any single job if it has interruptible pause.

A

Okay, so then it's it's! The.

B

Okay, it was yeah the.

A

Meaning of interruptible I.

B

Yes, changing actually but putting the correct meaning actually.

C

B

Right yeah, if I specifically write this job is interruptible. False. Okay, I want this job non-interruptible.

C

Because right now, interruptible relies on started status.

B

C

And so this would essentially add like created and pending to be like well if they exist at all. You know you can't do it like there's that Gap in there, where it doesn't, the configuration doesn't apply yet yeah.

B

Yeah currently interrupt interruptible includes the jobs that have interruptable through also jobs that, as you said, pending created and waiting.

C

For yeah and when we're creating just a single pipeline, that's not really because I don't think that's as much of an issue with is when we're like creating Downstream pipelines later on. I can see why this came up now, instead of with a single pipeline.

B

So you asked a question that I don't understand.

A

No I'm telling you okay, I'm, trying to understand, look if we change the meaning of interruptible.

B

A

um We basically uh if this is interruptible false.

A

B

No one can cancel it.

A

We won't cancel, we won't cancel directly the job right, but the job might become skipped. For example, if all the you know the the uh dependencies okay are not satisfied, for example, are canceled and will automatically be skipped. For example, yeah.

B

We are not touching.

A

The job directly right, but it can still it can still become interruptible because it's it's in a pending state or it's like in a created state. But since we are not canceling that directly, it must still be interrupted. It doesn't guarantee that the job is going to be running anyway. Yeah.

B

Yeah, of course, yeah it we are just talking about this. Auto cancel feature, we don't care about other stuff. It needs a job that failed. We don't care about this. We are only talking about this. Auto cancel because interruptible is directly related to Auto Council, nothing, more, nothing less right,.

A

Now, yes, yeah yeah, but.

A

Okay, well, let's take a little bit tomorrow, because I think we are running out of time, but we can dig a little bit more, like I, think on and basically changing. Considering that this, the default setting um on Project settings, sorry to change the meaning of interruptible, okay,.

C

Which I I think we agree? We don't have to do to do like a specif like a narrowly scoped Auto cancellation feature but would have the changing. The definition would help if we want to like. If we want to integrate those configuration options, it gives us flexibility.

A

Yeah I'm not sure how this would help but like it would be money to yeah dig a little bit more I. Think right.

C

Right yeah, so not I'm, not sure what we would necessarily want to do with that flexibility, but yeah. That is uh a way that we can get flexibility if we want it. Yeah yeah, yeah, yeah, yeah,.

B

Before closing, I have a quick questions, but it may be not important, so, okay, so the Fabio a couple of maybe 20 minutes ago. You mentioned that okay.

C

B

Have two cancel sources actually like that's. Why we have this Auto cancel yaml, syntax proposal right. One uh one source is on the pipeline, one sources on job failure, so this made me think about CI events. Do you think it's kind of an event, so a job failed, it's an event and result cancel the pipeline. A new pipeline is created. Anyone see how you want, and okay cancel this pipeline as an action. So can we consider this as a CI once or just I'm? Just uh I, don't know it's too much.

A

um That is a good point, um because it's a anything could be turned into like I guess like a CI fans, um but the the main difference there is that uh with CI events, then you would have a pipeline or a job whatever. That runs as a consequence of a failure. So.

B

It means like okay, a.

A

Pipeline cancel now we call you know we issue an event and you have a subscription to the pipeline console and you have to create a job that maybe uses API that cancels the the pipelines. This is more like a native integration uh to it, okay, um which maybe you know we can still use part of the Eventing system.

A

um You know still publish subscribe events uh to react and do like um Auto cancellation. uh We could still do that on under those, but it would not be a CI event.

B

Yeah I see your point.

A

Yeah, unless, in the future, we, you know with CI lines, we have other kind of syntactic sugar to to you know, create jobs that actually cancel a pipeline based on a specific ID rather than typing the whole job. You know using API and stuff like that. If it is like a much nicer way, maybe the future, a lot of the things could be done just through like a programmatic language, but I.

B

A

At the moment it will be more difficult to do something like that. Yeah.

B

Okay: okay, thank you. Okay,.

A

uh Okay, so I think we uh over time, so we have some option items we can follow up in sync and I just want to make sure do we have um a contributors blocked or anything. Then we need to unblock this sooner more, like a related to kind of. Maybe this issue yeah.

B

I think we talked about this interruptible, but we didn't talk about this failed pipeline. I think.

C

Yeah, um so the all right, let's talk again tomorrow about autocan Auto, canceling um I, think we.

B

Can have another meeting tomorrow if you are okay with this.

A

uh Yeah I think I think, let's do one thing actually. I would suggest that we are going to digest these ideas. Yeah.

B

Let's, let's think about this.

A

uh Yeah, let's see more, like you know, okay, is this proposal makes sense in this context, based on what we discussed. Maybe there are some missing cases or or things we would like to use differently.

A

Think and then we will set another call uh later this week. If we feel like you know, there's like a still stuff, we, you know we'll benefit from it. Okay,.

B

A

B

Write a summary into the issue, the department issue about what we actually suggest for this project settings, so we can also I will also finger there.

A

Yes, okay and yeah for this budget settings. Let's consider this more like a an evaluation of an idea rather than a proposal, because we actually need to understand the fully you know the implications of it, but yeah.

B

Okay; okay, thank you! So much. Okay,.

A

uh uh Stuck here.