GitLab Environments Team, 27 Jul 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: GitLab events and automation

Description

Notes: https://docs.google.com/document/d/1jrmYsQ6mlfnxzO1PUzjUzGBsy2UQqKGEXLl9pSY-UnM

A

Okay, okay, so so let me try to explain that so this is this broader story around. How do you want to compete with GitHub, and it feels like GitHub has been built with a slightly different approach in mind: why we iterate in a way that we deliver small changes and try to build larger features later?

A

How GitHub did that they decided to build a solid foundation that has been well designed with all the you know, Primitives and all the building blocks that make it easier to actually build on top of them later, so they they managed to build a really robust Eventing system.

A

There is probably close to 100 or even more I haven't changed at recently events that GitHub is being able to emit so and you can subscribe to them in your actions right.

A

They do have a quite good catalog of the actions and Marketplace I think this is how they call it, and then they do have actions like themselves right, a reusable components that you can just you know, pull from Marketplace, injecting your your pipeline just subscribe to some events, and suddenly you know it's going to work. So our response to that is that we want to build the catalog, which is the CI catalog right now, the CI catalog hosts or templates. We made some changes to the templates to make them a bit more reusable right.

A

We introduce the interpolation technology, which is also something that GitHub has in to some extent, and we, we are, you know, delivering a couple of other changes to templates, to make them more like reusable components, but the components based on templates are not not going to be the replacement for actions, because actions uh are designed in a slightly different way. So our templates describe whole pipelines, or you know many jobs that you can merge into your configuration.

B

Right, basically, we have a single pipeline definition and we just merge it and generally.

A

We can have child pipelines in there like that, but it's still you know the the current templates operate on it like whole configuration level right and actions are a bit different because you can use actions to compose individual individual jobs right and um there are some principles of how those operate, for example, the principle of making it easy to pass data between actions in a way that you know, one actually generate outputs.

A

The other action takes in you know those outputs as inputs. So our response to this specifically is gitlab steps right. So so that would you know, make it more like GitHub um solution. So if CI catalog and steps, we are able to model actions, but there's one missing piece of our puzzle: it is the whole Eventing system that right now does not exist at gitlab either right. So this is something that we want to build like. There are no abstractions, no code drives available in the code base to support this to support Eventing.

A

So uh my blueprint, which is still unmerge the GitHub events platform blueprint, is an attempt to build all those abstractions that will make it easier for engineers to emit events from within the code base, with a very low cost. Similarly, to incrementing a prominent youth counter, you just put emit something, and suddenly you know it's it's there and the other teams can consume these events, um of course, like the GitHub events platform is just a foundational solution right, it's a solution. It's it's!

A

This desired document describing how to introduce this actual layer of abstraction for managing events in gitlab. Then, of course, if we we would need to connect that abstraction into the CI itself right. So that's the separate design, though called gitapsia event and uh with with all those pieces of a puzzle. If we do a good job in you know connecting the dots and building all those things, we should be able to provide users.

A

This you know experience that is quite similar to what GitHub offers and, in my opinion, that's a major competitive. uh You know Gap that we have in our product and it would be really cool to fill it in. There is the I I, don't know if you have seen that there's this document of mine.

A

uh That, uh like let me link that from from the agenda, that's the summary of uh of the feature Gap and there is a bit more in there, because it's not only uh events, steps and catalog, but it's also making it easier to automate things with all the steps we are thinking about, either building a domain specific language that we would evaluate in a different way than a regular job right. So it can be maybe a domain specific language we could evaluate in much less expensive.

A

So if we build a language or user language that is hermetic and isolated by default in a you know, stack virtual machine, for example, that it runs on. We won't need all those virtual machines and this complex technology to provision them and we could like create. You know a single Runner that has capacity to run thousands or even millions of simple scripts using that language without all the overhead or virtualization, and things like that.

A

So there's also an idea to leverage web assembly to do that when someone needs a bit more flexibility and hermetic language designed to operate with github's apis is not enough. So there.

B

A

Many things in there and uh I think the vision is quite solid. Of course there are gaps and if you have any ideas about how to fill those gaps, you know we would definitely appreciate your input. The the challenges always here at the gitlab is capacity and they're, like no people available to build this thing. So.

B

A

My tldr and summary. So if you have questions just just ask.

C

I was not aware of this feature cup analysis, I, think yeah, I think I haven't seen this, but I definitely saw the blueprint or something about the web assembly support in runner, yeah.

A

Yeah, so webassemble is just one of the solutions: the Hermetic language, either custom built or a language like starlark, that's also another another solution.

B

um What I would so.

B

I think it's always a very bad product strategy to try to catch up, meet someone and I think what you shared is very important, but my question would be that what do our our users actually need and want, and especially what are the shortcomings of GitHub actions? Yeah.

A

B

For that, and and and uh my first idea just to give you some idea as well where, but but you haven't spoken about it and but I would strongly recommend looking into is to make our I don't know how to call them now. Pipelines, uh testable and kind of runnable, locally I, don't know what it actually means, but testable. Definitely so that um and.

A

So basically I don't know if GitHub.

B

Actions is such I, don't know if they can test actions easily or not, but I think that's something that could be a big thing if we can design for that already yeah.

A

I I think if you read the Communist GitHub steps uh design dog it already covers those items like uh you should be able to easily run a set of bitlab steps with a CLI tool locally and the the it's it's going to be designed in a way that it works exactly the same way in the CI environment.

A

So I I agree with you and I think that we have never really been trying to catch up on GitHub here and that's also the reason why these features do not exist yet right, but after actually listening to our users and customers, it's clear that they not only want things like that, but they also need them and we know, but we also we need them too right. It's.

A

We are the the the the first, probably the biggest customer of GitHub gitlab CI, and it's clear that you know, even with the you know, triage serverless, which it's now called triage Ops do you? Do you remember the project? It started this as a serverless.

B

A

Native at the engineering productivity team managed to out of that, and they further extended it. It still runs somewhere in Cloud, run right it's yet it could easily run on the gitlab itself, with the Eventing system and the much less expensive technology to run simple automation, script scripts than you know, on Virtual machines, or even the cloud run. So this is something that we need. You know ourselves, we are, you know, extending and building a fancy project that otherwise would be just part of the product and that that's probably the goal.

B

Yeah um I don't have actually anything yet and thanks for sharing these it, like yeah,.

C

I just wanted to add a few things. First, to add to victors I mean you can be number one if you are repeating after someone, because they are number one you are repeating after them right, so you have to come up with something novel to beat them to be your number one, uh and uh the second thing is I, have previously I think shared with many people. I think a lot of people are in there.

C

I have this automatable devops issue and oh um I feel like what you have just described and discussed is kind of that issue picked apart. I created it two years ago and I talked about components, reusability and all of that and the missing piece. That is there in the issue and we haven't discussed. That is the is a possibility. I'm also talking this through.

C

You probably know that, but I'm talking through because we are recording hello, people who watch this, and so um the missing beat is a way to describe a proper workflow which is not just a direct as a sacred ground, but something that can run uh for a longer time like a week and doesn't necessarily consume resources for the whole duration, and it can have conditions and loops, and you know waiting for external events and so on and so forth, and it doesn't have to be expensive as well.

C

So like um basically right now, I I see the need for this everywhere. um We have this issue for as an example for the need.

C

For the external side, jobs and linked it in the notes. um Basically, the proposal is to have a new special syntax in the CIA mode. That waits for an external signal blocks the pipeline and then when it gets the signal- and we continue- and we want to use this to wait for edit of saturation and when it has finished the pipeline can continue. But it's just a one single particular use case and we are adding Syntax for that.

C

I mean there can be so many other things that you know we the end users may need to may need to change, may want to chain, and that's- uh and these are potentially steps in the workflow. So we are kind of building everything, but not not the the most important bit, I think, which is what would beat GitHub actually I. Think because they don't have this.

A

Yeah I agree with that and I think that the reason why we are not doing that right now is that we are probably just missing a proposal how it could look like so in in the CI event, blueprint, there's an extensive discussion about syntax and how we could actually model workloads and subscriptions and connect it to another one, and that's that's probably the place where we like. We have around five proposals right now. Each of them is something that I'm not particularly happy with.

A

Yet so that's you know where, if you have solid idea about how you could do that, like that's, probably a place where we could, you know benefit from having a proposal for this, because you know it's not not actionable to just say: let's do something better than GitHub right, I agree like everything everyone agrees that we should right like how to do that. How to do that is the you know the difficult part. So if you have any ideas, feel free to contribute there um I.

B

Think the how to do that is the second most difficult part. They.

C

B

The really difficult one is what what Mika spoke about is the. What would be that. So it's that it's not the, ha but but even the the topic and and up to this point, I'm not very familiar with GitHub actions, but most of what you shared is more like: let's catch up with GitHub actions, but there isn't I, don't know if there's anything how we would move forward, how we would bypass them again.

A

By how I meant also? What right? Because it's uh like, maybe just.

B

A

The proper word, but right now there is no description of what other than the five proposals we have in the CIA events, blueprint, yeah and I, and I think that, probably if, if I, if I, if I had to think about where we can, we can, we can actually differentiate, and you know build something better that that's the good area to focus on. But um we would discussed briefly with Mikhail the last time and I'm and there are probably more questions than answers at this point. So again, it's not really actionable.

A

So we would need to brainstorm a bit. uh What and how of you know this? This workable definition and I do strongly think that it should happen inside the file like we should model those workflows not in the UI, but instead to do that in configuration files.

C

A

C

Important stepping stone to understanding what. How is the realization that this is more than just CI like product wise again, we discussed that just saying it on camera and it's important to realize that automation is I mean hopefully for the whole develop cycle and not just for shy under the cover. It can probably even should use the runner in some shape or form, but conceptually all right, I saw other requirements like when I create a label and then add a label on an issue.

C

I want a comment to be added as well to the issue that conceptually product wise that has nothing to do with continuous integration right.

A

Yeah, that's just true, but like this is, is also how the product looks like currently right. We have a ton of features outside of the verify stage. Building.

B

A

Top of what is in there in the verify, like all the security features, govern compliance. That's not necessarily A verify right, but it's like.

B

I think I I totally agree with that. I think what's important here is that even our terminology, calling givitlab, Ci or gitlab cicd, is limiting just put one by the other like gitlab Ci versus GitHub. What was it called actions.

A

Right I know like basically, if I had to be honest, I would say that it was a mistake for us not to uh move forward with our serverless vision, because we would have a generally compute platform like we could do anything and would be disconnected from a CI and statuses and Runners right. It would be, you know, run something in a serverless way and, like you know you can, you can consume the results any any way you want, and we work quite close to achieving that objective.

A

So right now you know this offering does not exist um and- and we are kind of constrained in the CI space, because there is no alternative right with the serverless. We could have this alternative right now. It does not exist. Everything that we've been we had built for like a year, probably like, like all like, not 100 of gold, has been removed from code base like there is nothing left.

A

So we can't, even you know, build on top of that or or try to extend it.

B

A

It work right because it has been removed and it will be very difficult to even like bring it back. So, unfortunately, we are constrained. Of course. It's also a matter of Nomine cluster. We can. We can just not code thing CI right, but under the hood, it's still those things still use.

B

A

Ci, so that would be a bit, maybe dishonest, but well we don't have serverless. We don't have this generic compute platform right now.

C

Yeah we we almost have, uh we almost have I mean we just need an API to run a job and not show it in the UI. Basically, that's the execution. Api I have an issue for that as well.

A

I would say that it's uh it's not a very good feature, but uh in some limited ways we do have detached jobs. That will never appear in like that.

B

A

Those are detached from Pipelines uh like in the UI, because in in practice you cannot really run a job separately from running a pipeline.

C

A

Yeah, but those are the details right, yeah, the implementation, details, I, think. If you want to make the progress, we should more focus on and.

C

That's what I was trying to point out yeah that we need to conceptually decouple from CI, and then we can have a clear region that this is what you need to do and then we can figure out how to do it. Use Runner under the hood. Do that do this anything else have the events platform and so on, but conceptually we need to understand what you want to do and that's automation, I think for the whole cycle. Yeah.

A

So I I think I would agree with that right, so this will directly influence the proposal in the in the githubs here events, but maybe maybe it's just a matter of putting an additional indirection layer between the gitlab events, platform and GitHub CI uh events design dog right, and that would be this.

A

This additional layer would be the thing that you are describing and gitlab CI events feature would become just a consumer of that additional capabilities in, in that you know middle layer, and then, with that you know, we could then just build uh another feature set built on this on this thing. That is in the middle between just plain events and nothing else, and you know gitlab CI, because.

B

A

Gitlabs here, I think, is still going to be required because our customers are expecting. It will be available so uh yeah. How did this middle layer could look like you know? It's still not clear. So in order to make this actionable, we would probably need to brainstorm of how it could work, how it could fit in between the GitHub, CI events and and GitHub events platform um layers.

C

Yeah- and this is very similar to what we concluded with our previous conversation and Victor- we wanted to bring you in here and Nico as well, but he's on PTO at the moment.

C

um So what I suggested we do is we environments work together with verified to move this forward somehow at least try.

A

To verify, because right now, the team that is motivated the most probably to move this Vision forward is the package team, because they need to do things whenever someone is pushing a package because of compliance reasons because of different reasons like we.

C

Have seen yeah, we have similar means as well. We need to do things when stuff happens.

A

Exactly yeah, so uh so let me think about what we can do to actually move forward with this common vision, like the best tool I have available for us right now. Is the engineering design workflow right? So that's that's the workflow in which we can write a technical like semi-technical document, to describe the vision and describe how it connects to the other two like the the gitlab CI gitlab events platform that is below and the gitlabs here, events that is going to be above um um and uh I, probably like.

A

Don't have another recommendation, because for me right now, it's even difficult to imagine how it could look like, but I do hear you and I do see why it can be beneficial. But the the challenge with software engineering is that tiny, tiny, Details Matter like a lot and one tiny detail, can change everything like completely and we need to. You know, capture those details, the most important one somewhere.

C

Yeah I agree with that. I also thought proposal would be the best thing to start with. You know we can probably copy many bits and pieces from the existing proposals about the like what we want, but the problem isn't have a new proposal. I suppose will that bigger goal and.

A

So basically, I have some some thoughts about about that. So let me try to um share them so GitHub critlab events platform. This foundational thing is going to be designed in a way that anyone can emit an event right. There are going to be the gateways, also an abstract, Got Away in code, so you can, for example, build a Gateway that is going to intercept all of the events filter out those that are irrelevant, maybe and then just just pass them through to another feature like gitlabs.

A

Here, events right, so we can have also this got away that can fast all the events that are required to a different feature or different area and consume the those anyway we see feed right. So it's not like, so this is going to be also this fun out mechanism right. So there is a single event generated and there are multiple getaways for it if it matches like two or three or five or ten gut ways that this event is going to be duplicated, so that other features can also consume it right.

A

So another solution is to not to make this. What this thing that you want to build: Mikail like as a middle layer between events and CI events, but instead build that on the same level as CR events as just a different access mechanism for consuming events. For example, right yeah.

C

That's what I was thinking.

A

So this would probably be a bit more practical uh and easier to understand, so, maybe so anyways we, we just need to start brainstorming sessions somewhere, so maybe, as the first iteration just open a Google doc, you know write your thoughts in there. I will provide mine. We will invite other people. Maybe something will come out of it, and maybe you know after a couple of iterations, we will be able to describe like copy paste that into a design document.

C

Sounds good yep start the dock.

A

A

Do you have any capacity in the environment team to work on that? Are there any Engineers except me, tell you.

B

A

Really passionate about that, what this like clear, are there any passionate Engineers who would like to work on that and are available to actually do it.

B

um Like I think Yes actually, uh because to a certain extent, we need this functionality, as Mika said, as.

A

Well and many other teams need that as well and so uh because, if I had to, if I had to evaluate the amount of people and time that is probably uh to engineer six months, something like that three Engineers three months or four. Something like that. So that's not like the largest item. But it's not. You know a small item.

B

A

So it's medium medium size.

B

And you you imagine like this, these Engineers work full time on on these changes.

A

Yeah, usually I I'm, usually referring to full time, because I think it's lots of efficiency to make people like contact switch between different things. You know everything.

B

I agree just I mean we often have the context as we are waiting for yeah. Of course, yeah people but I see what you mean.

A

B

A

Actually, it might work yeah, because we might also combine forces with verify in the verify we we are struggling with capacity, but maybe there will be. You know one engineer available.

C

We also mentioned package: maybe they help someone yeah.

A

Also also package, which is not very.

B

Packages very, very shortstopped, uh since.

A

Like everyone on Tuesdays yeah, so let's think about that. Let's start the Google Doc. Maybe then we will probably need to have some.

A

um So what what really helped me to? Actually let me show it to you uh what greatly helped me to actually get get us to work on on something. Where is that I would just find it just giving over okay.

A

Architecture, it's uh there's one blueprint in which I, uh where is that um it's.

B

A

And uh partitioning.

A

Here and there is this iterations okay, so let me show my screen, so this is the thing that I did. Actually you know it's very simple gun chart in a design document, but it greatly improved the way in which we could plan out the work and uh actually get people. You know like schedule their time to do something, so that was really, of course, like it's, it's slightly uh outdated. We are probably not here, but we are here, but there are major milestones and work stream described. Something can be done in parallel.

A

It's also visible in here and I. Think in this particular case, where we have a couple of design documents like we may not be able to reason about how to do that without having something like that.

A

So I don't know it would be helpful for you uh Victor, but once we are once we know what we want to build. I can collaborate with you on building this gun chart and maybe.

B

A

After you see that you can actually make a commitment to Mike I.

B

Think that that would be really good uh much better than what often engineering allocations provide three to nine months.

A

You know, then it's always. You know twice more more time, plus 30 percent. You know yeah.

B

But always yeah this this was this was this was nice to see actually um yeah.

A

So I can paste the link from the agenda as well for your reference.

A

Oh I think that you know it's. It would be a major win for us to actually build something this year. That would be like completely amazing.

A

So I also think that at some point this year this is going to appear in the product okrs like product level. Okay, ours for the whole company, is a major major. You know item to come people GitHub. We still do have this care about compete with GitHub right.

A

Yes right now with AI, but then it's.

B

In my opinion,.

A

At least it's not much smaller item than like AI in in terms of competing with GitHub right. The AI is this. um This thing that is right now very inflated, maybe in some ways, but the the you know, events, steps actions, that's the fundamental value right, fundamental value that is making ggus productive without doubt. So there are maybe some doubts with AI right now, but with this there are none. In my opinion,.

C

A

C

Me of service mesh, it.

A

Was on fire yeah yeah service mesh used to be a very popular item some time ago.

B

A

Know people are using meshes is that what you're referring to.

A

C

B

uh It's really about the time frame because, as you mentioned, that there are these competing proposals today in in at least in the CI events Mr, the.

A

Digest proposals for syntax right: it's not the proposal of how it should work, but how to describe those relationships between events pipelines in a you know configuration files. But if you want to build what Mikhail suggests it's kind of decoupled from CI, then it's we probably can do that without um being blocked on CR events. Proposals.

B

I think what we need.

B

I think what we need shouldn't be actually that decoupled for CI, at least my immediate ideas are really around like it's.

B

It's more that it's, um for example, one specific topic, I'm thinking a lot about is to have a self-contained release artifact and by itself, contain I mean that the artifact has the logic on how to deploy the application. That's referenced in that artifact.

B

And that lands very well, it's up for regulated Industries, where you have this very clear deliverables that one team has to give it to another team for the deployment actually. So.

B

And and there the idea is: okay: I want to run this artifact I want to deploy from the artifact. What's included in that artifact. What.

C

About I'm, not generation and secrets.

B

Exactly um the I haven't seen any great solution in the industry, yet the closest to this is the cloud native application bundle specification.

B

The idea is simply that um the bundle knows about the inputs, it needs to receive for environment variables and it can reference secrets that it should be able to access in the environment where it's run, and these are defining the bundle in the sense where.

A

Does it get deployed to kubernetes? Probably it's.

B

It's totally platform independent.

A

Like how is that possible like because.

B

The logic the deployment logic is part of the bundle, so, basically, you need a runtime that can open up. This bundle set up the environment for the C to access the secrets and the environment perhaps necessary and run the image that describes how to deploy itself.

B

I mean another part of the bundle.

A

How can you describe how to deploy something without knowing where you are deploying into.

B

A

B

What you mean, uh the deploying into part, is part of the environment setup actually.

B

C

In our case, like.

B

In hitlab's case, if gitlab could run such a bundle in the Pipelines and then you specify that it should be deployed to the gpro environment and gpro knows how to access its cluster. In our case, it's a cluster, it's a kubernetes cluster, but in the other case it might be just AWS credentials and the invoke it's called. The invocation image in the bundle knows that, yes,.

A

This is, but isn't it like that the pl, the environment setup required to deploy something? Isn't it like 95 of the deployment uh procedure like it's, if I had to deploy something, it's like 95, the environment and five percent? That is everything else. So do I understand correctly at this deployment bundle allows you to describe this five percent, whereas the 95 you need to provide as an input.

B

In a sense, you are correct and that's why I'm not happy that's one of the reasons why I'm not happy with the with this setup.

A

Okay, anyway, so uh yeah, we can definitely think about that uh yeah yeah. But uh my my like feeling is that with the CI events, it's quite refined vision and there are not many unknowns with what you want to build. There are much more unknowns, so I think maybe the next steps would be you're describing somewhere in a Google or, for example, um the use cases that you have to you know maybe we'll be able to find an alignment between what you want to build and uh either.

B

A

Or maybe actually another you know solution would be better um better like better for for this purpose, but it's very difficult for me to um you know, give that recommendation without actually knowing what you want to build. So maybe we.

B

A

Like with describing that it's in parallel.

B

Yeah, actually, from my point of view, I I think that most of our requirements can be actually fulfilled by CI events, except that they shouldn't be called CI events.

B

um That's that's my kind of like I would say eight. Ninety percent of our requirements for sure can be food.

A

Yeah, because what what's the interest like typical yeah, we do not plan to describe those events in GitHub, like it's probably going to happen in separate files, probably like dot gitlab workflows. So uh we can instead of using gitlab, CI events. We can call this feature gitlab events and even though you know initially at least all those things will run on runners.

B

A

From it in some way, so maybe maybe that's the most- you know obvious historic solution here.

B

I agree: that's why um that's why I said that I think we can have some engineering uh time dedicated to to be a doubt that part as well, because it's just like a very specific use case that we would like to have is there is a package that got published now deployed, and today you, you have to write it into your pipeline that in one job publish the package in the next one I deploy it instead of just noticing that there was a new package.

A

B

Or update manifests based on that.

A

And that's how we could do that. We could, for example, uh at an event, Packard package available right then yeah even GitHub events. You could describe a job, that's going to deploy that package exactly.

A

You know the package might become available through a build where it's being built, or you can build that externally and send it to gitlab, and both actions are going to emit the same event and then deployment starts so yeah. There are many like I I, really like events, because dogs allow you to model your workflows in a way that is completely unavailable right now, like what we have right. Now, it's more like procedure with events. You can move to a bit more declarative configuration with much more flexibility and additional abstractions different data sources.

A

So it's just the next level of flexibility right compared to what we offer today.

C

How to add to what Victor to extend what Victor suggests- and this is step one as I see like the step two you you can imagine that we give people tools to build operational dashboards that give them buttons to run or close. So, for example, okay, you have you got to deploy it automatically. What if you want to roll it back or what? If you want to say if, during first two hours, this threshold is crossed, which is done by monitoring, not us like.

C

Basically, this alert fires, which was triggered by this threshold being crossed then roll this back.

C

What is it has nothing to do with CI events, CI, specifically CI CI right, but it's a workflow where you deploy things than you for two hours wait, and while you wait, if this event happens, which is a threshold being you know across, then you do this if not and workflow. So.

B

Actually, it's I will complicate a little bit that so, let's, let's take a canary roll out like.

C

B

For for one person, you monitor the metrics if they are good roll out 10 you monitor if they could roll out more or you roll back if they are not good. So it's like it needs to handle both situations and it happens. 100 outside of gitlab or all.

A

This thing so that that's really cool and I can give you a some context about our immediate plans for what comes next after we deliver GitHub events, CI events, not here events. We want to make it possible for users to subscribe to any arbitrary event, and there is going to be a gitlab Sync, API endpoint, into which you will be able to push events right, so gitlab receives an event, presumably in the cloud events, format and with GitHub events there's a subscription for it already.

A

So the event can be, you know, threshold 10 achieved or the rollback requested or anything else, because those are the arbitrary events and with the proper getaway implemented, we'll be able to send them to the events dispatcher in the gitlab CI events here, events non-sea events- and this will allow you to do something right. So that would be something that, in my opinion, would almost entirely cover your use case.

C

It does cover, but I think I want to point out an important difference. I think an important difference where and if you think about events, it's a building block and what I'm kind of conceptually Imagine to give user a higher level building block, which is a workflow that way you can manipulate different events as as it's a single it's a workflow like this waits for that this waits for that, and so on, not just okay event. What happens event? What happens? That's a lower level kind of lower abstraction approach.

A

Yeah and that's also on the immediate roadmap, because, with with that solution, uh you can do something when we see an event, but after you do that you can also emit another event, also arbitrary one, and with that in mind, you can it's not and even do something. It's event. Do something emit an event. Do something Emit and even do something like you have infinite.

A

Almost infinite group probably need to monitor how long it is. You know how long this transaction is, but this makes it possible for you to model any workflow. You would like.

B

Anything else from anyone.

A

Maybe just action items, so uh maybe uh so two Google Docs one uh to describe uh how this technology could look like. Given what we already know about the club events in dilapia events, design document- maybe Mikhail- can start out.

A

I will try to comment on this as soon as is it available and mix, or maybe you could take this action item to actually build a simple list of features you would you know uh uh you potentially use gitlab CI events for and in my opinion, if we build that and I will ask the the package team to do the same and in verify once we have like a clear list of 20 on or 30 features being blocked by. You know this single abstraction that is missing right now.

A

I would think that it would be very clear message uh to our you know: product leaders, for example, that this is something that we actually need to build soon.

A

Doesn't make sense.

B

Yeah yep, it does actually.

A

Cool then I, we know everything so yeah feel free to send anything. You have to me all right. I can comment on that feel free to ask questions. If you have other more ideas, we should brainstorm, feel free to schedule meetings I'm available for me, that's a very important feature that we would really love to see being built so yeah.

B

Cool. Thank you for what I call.