GitLab Delivery Team, 25 Feb 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How Delivery may handle tagging

Description

The Delivery team discusses what the future of component tagging will involve to ensure a central location of how components interact will be stored in the future. https://gitlab.com/gitlab-com/gl-infra/delivery/issues/685

A

All right so to restate the issue that we need to solve for issues. 685 is what I created to address this problem. We currently tagged with our major/minor timestamp gitlab sha, followed by the Omnibus sha. This made sense when we created it. However, we are now starting to add the add to the list of packagers that we are using to build stuff. So we now have our helm charts and we also have CNG that we will start tagging here in the near future and having a tag that contains that omnibus shot.

A

Doesn't it entirely make sense, so I think we need to figure out what to do with that tag and how we could explicitly have necessary information. So we know what precisely is being deployed at any given moment in time in a quick and easy fashion, as well as not hinder our ability to get to a solid mechanism in the future. That way, we try to prevent delaying pushing sidekick into production if possible,.

A

So let's get started jarv you have a so.

B

Yeah, just starting off I guess: how do we feel about JSON files in a single directory when these tools.

B

And it sounds like maybe we're okay having the JSON files, but maybe were not okay with putting it and release tools and Alessio comments like organizing it by major/minor I. Think that makes a lot of sense. Yorick, I'm curious for your comment. Like would we combine maybe release tracking now release tracking we're, not writing anymore JSON files right. So, though, no.

C

So the JSON trekking in the deployer is gone. I know I, think of it, I don't know if I actually remove the existing JSON files, whatever I personally, would prefer to avoid any such setup, largely because we get the same problems where we sort of mix two different purposes in the same repo. Basically, I look at database and all the code.

C

You know on the surface, nothing wrong with it, but it gets a little hairy and there I found also that at least with the deployment striking using the API, it's a little, especially if you have to append two files which I guess. If you don't want file perversions, that's when you should but appending it, yeah gets kind of messy.

C

What I was thinking of more this yesterday was that we could maybe either upload adjacent fell to the.

C

To the release so that the release feature not the deployment, but then we found oh, you can't actually attach files. It has to be like uploaded elsewhere now, I want to double check, so I'm, not sure. If we can do that. If tax, let me just quickly check but either way that the point would basically be. You would get you'd have to version that we deploy it you'd sort of correlated to a get tagged and then that get tagged contains the actual JSON or you know whatever. It is.

C

It's still kind of the same as tracking it in a repo, but it's not like as part of the physical collection of files, although you of course still get the metadata when you fetched it, but.

B

Which project would be the canonical source for the tag metadata or what all tags have this metadata? So.

C

I would lean towards using the github canonical repo for it largely cuz, that's I, guess what most people would expect the data to be that does get a little tricky with security releases, because in in a security lease we yeah we've recorded information there we'll probably go in these security repo, but then you have this weird split where it's like. Oh you know, if it's secured least, we have to go there and release tools may not actually be aware of that difference.

C

So when it records a deployment, it just gets a conversion number an environment and a status. That's it it doesn't actually I'll from that hey. Are we dealing with a security release or say something else? I, don't.

D

Think we can do so because we have to bump the version, an omnibus stick. We generate a new sha and that Shou would contain the the Shou of the rates version. So we need this to be stored somewhere else that we can collect or the the final shot after we tag update everything because we have to yeah yeah.

C

So what we could do is, since we have the security split. We could just let's say, for example, we create a new repo, whose only purpose is this, and you know if it's a dedicated repo, then you can do J's the false mystically and you could even use issues I guess because it's not used for anything else. I think for me, it always comes down to what we really want to be able to do is get a get tag created, get lab release for it and then just upload some arbitrary artifacts to it and yeah.

C

If you kind of feel like that should be the way to do it basically cuz, then we could get the first. You get the tech, you figure, ok, what score's pulling release oh and we need the artefact there. No first until Jason, let download that off we go. I was.

D

Thinking about having plain file database, which every folders is a tacit release and then kind of how would we do this in communities? We have several JSON files that maybe we have. We start with a simple one, which is components that JSON and has a well-known structure which is name of the version file, because I don't want to write another mappers that changed from the version mapper v to the name of the he in somewhere else.

D

So we can stick with that one, because it's it's the same in every project and the value is the the shell whatever we want to write down. But if we want to expand this, we can just write a new file in that folder and we can add other kind of metadata but more important with me.

D

If we want to move away from this and go to some kind of kiss or value, we already have the structure in place because you just work the folders and then you can convert this to Yama or whatever it is, and you have the key value for everything and and if we just keep it simple in the in the repo, we already have plenty of API calls in our tooling. They will just download something and that's something we can get the component versions right.

B

I think one of the problems I see is that we're talking about tags, but it's not even clear like whether each release like we're not tagging, to get that EE right now. The only tag on the us get vibe I'm, not sure. If we will start tagging get that ee, and then we have this issue where we might have a charts release that has a charts change, but no other change like no change. So then, in that case, like would be tagged.

B

Everything I almost am beginning to think we kind of go with this kind of flat file structure and these don't necessarily need to be tags. I mean basically it's just a release that corresponds to component versions which may be tags. It may be shah's, but actually tagging I guess, like yeah, we'll probably still need a tag omnibus gitlab because it triggers the pipeline's for the tag pipeline. But I don't know. Are we just talking omnibus key 11 charts and that's it? Are we this parts confusing to me? I, don't know what job.

E

Before we go to answer that question, which is I, think a completely separate problem now important but separate problems, can you check out the link I gave in the doc for the future called release evidence it actually might be interesting to go down that route, which would allow us to create a separate project, create issues based on deployment which will contain all of the information who deployed when and so on, and then see whether this release evidence can be used as a feature.

E

It's like the output seems, like you know, like proper JSON object there, and hopefully it will allow us to do things over the API as well. I, don't know exactly what he does it.

F

Looks like it's collecting milestones and then those milestones have issues. It doesn't look like you could directly associate issues, so that seems like we'd have to first create the milestone and then associate a bunch of issues with that milestone that has metadata in it, and that just seems like we're kind of I, don't know around right.

E

But that also means that we don't store JSON files anywhere and we use a feature. I, don't know exactly what this feature does, though, what is it supposed to do? But I can ask the release, release feature team, yeah.

F

I'd be curious to see what the use case was that they intended or what they created this for I.

C

Think it's kind of similar to where, on github we very quickly give an example. I think ye of M uses this where they essentially use their github releases feature as sort of a change block. Let me quickly pull that up so doc.

C

C

There's something wrong here: there we go so that link the way. Understanding github, you have, you know simply tax and releases and I think releases are always associated with tax. It's been a while since I use this, and then you can just upload arbitrary stuff to these I I used it in the past as well. Some projects when I still using get up this.

D

One seems to be related to mine some, so you should. It looks like you have to release a tag with the same name of a milestone, and then it will do the magic and finally.

C

I think you could create them manually. Let me just quickly check, because I have the project that I think still use them publicly. I'm talking.

D

About our oh yeah,.

C

Yeah so I get up you, you choose an existing tag or you create a new one, and then you can give it an arbitrary title and I'll put stuff to it. So that's I, guess kind of well. The least in was going for except you can't give it the title. You can't upload stuff and you can be created using the UI for some reason which no.

D

You can create with UI it's just.

C

D

Have to create a tag, and it there's an extra top box. If you write it, that the content of the release.

C

If I edit, yes.

E

C

E

Say say: this is an option right like we need to investigate, obviously, but say it will create milestones. We need to take create tags. Does it matter? If we create a new project, it will be only there there to store this information. Does it matter whether we're gonna overload the project with milestones?

E

D

This feature here doesn't seem to allow you to write. Anything here is just collecting evidence, which means there has a way for finding related information and dublicate in everything will would not be helpful for us because we have issues in there, but, moreover, we just want to straight.

E

D

E

Kind of suggesting this, as as an option to increase the visibility, so that's one of the assets that I've placed, so we are already creating issues for feature flag rollout. So we have that log thing that Yuri created and we are abusing project to store issues to store some data there.

E

Nothing is preventing us from extracting the get the information from the get tag that we currently store in the auto deploy tag, wait order, get Alicia and blah blah blah. All of that we have and for every deployment we create. We can raise an issue note.

E

All of these things out know the details of who, what, when and then, if necessary, create a mouse I, don't know what that milestone and tags are important here, but I'm gonna use an example of extreme case right if we need to create a milestone in order for us to be able to create a tag in order for us to be able to create this release, evidence that is all within the github API and it's all very simple to do.

E

I I think at least, and that would kind of give us a free pass of not combining release tools with this JSON files. We know the problems with this and if it also allow us to do this on ops, for example, it then just mirror the project on comm and so on. So it's kind of simple solution.

E

Let's see solution for this part of this problem,.

B

Thankfully I I think, like forgetting our dog, fully and cookie. You know it's like it's a lot of pain because I think we'd have to pack information and issues.

E

How are we packing too much information? We would have to create JSON files, it yeah.

B

But it's overloading issues or something that they were designed for. It's really overloading things. It's just like it just feels weird like you would have one release per milestone, let's say and then in each issue you would have issue per component and in the title you would have like the versions or the author name be the component name.

G

You know you could think of like.

B

D

Over the nation's parsed, this inside every place where we are ready, parsing the version files and.

B

And issues aren't replicated between ops and calm, so that doesn't really help us that much here and I, really like it just doesn't feel like this was designed for the problem we're trying to solve I.

C

Think the least from a release tools perspective using issues that the biggest issue there is that we can I have to basically parse markdown using regular expressions and we control the format. So in theory, it's easy, but it only takes one person to go in or I, don't like this format or something like that and the whole thing sort of collapses, and even if not it's it's just kind of difficult to do this in such a way that you know. Okay, it's strict enough people, whatever accidentally, you know, find the value below it.

C

Instead of the the one above etcetera. No, you you can take that step further, basically, create issues antibodies, just Jason, that's a deep our step, but then you kind of get a point like okay. Why are we using issues in the first place and if you're gonna do that, then I would say: okay, let's just put them as a file in a repo, because then at least it is mirrored- and we know that it's a JSON file so way people see they're, like oh I, probably shouldn't mess with this manually, so put put a say.

C

Given all the sort of options we have and their limitations having a V is a separate repo. Where is I, guess one JSON file per version with all, or at least a directory with one or more files in it, but sort of a one on one link between your version and the data that will be fairly doable. It's not the most pleasant approach to work with I, guess and they're implementing might be a bit tricky because.

C

I'm not sure if we have to modify just only bursar release tools or both because.

C

Only bus is probably well it's doing. The builds the package, so it knows probably you know what helm Jared it's sort of what help version, which you know only restriction whatever, but opening bus doesn't really have the code in place. First I know to interact with the API and etc so it would have to I guess, trigger pipelining release tools and their release tools has to do the extra work. So we get this Ruby circle again and.

E

This first problem: we are trying to solve them because I was under the impression like in the discussion point. It says we want to use reduce tools to record the version every time. So, if you're recording the version, we're not need, we don't need to parse anything afterwards right like we only want to have this as evidence.

E

C

E

C

To parse it, if for, if we're going to later, use this, for example, for well for recording deployments, for example, the way that works now is the deployer starts a pipeline and gives you the version, environment, status, etc and their release tools takes that version and says: oh, the the get like Aisha asks this and the only Bashar is that and then it does a little extra work to figure out how to do trig, Italy and then everything sort of builds on top of that I think.

B

I think all the logic door could go into released. Also, release tools would gather all the versions, write it out and then anything else that needed to consume versions would just you know, fetch the file and that's it I, don't think we would have multiple projects lighting, but we just have release.

G

Terms would be the.

B

Single writer so I think that in that sense, it's it's fairly simple. I think there is a question of like would we write, tops or write to get like calm, because now, like you know, what is the source of the? What is the source of the commits one key like that comma ops and you have to make that decision, but other than that, it's fairly straightforward, yeah.

C

So my point more, there was, if we start going down this path roots, that creating issues of milestones, it's quite a bunch of steps and folders, say Oh after you know at this milestone, maybe these levels etc.

C

If it's just a JSON file, it's just you used a pair upload, a file, that's it so my point was more like we should keep it as simple as we can get it, especially keeping in mind that probably at some point we want to use the gillip releases feature to track this data once we can actually in terms of where I think, since we are moving released, all stops. It should probably just be own ops, because this version data is not particularly useful to developers, think they don't care which Shia was deployed.

B

Yeah I think that I think that makes sense and it kind of sucks that the mirror would be the other way. You know be from ops to get calm, but I think that probably would work.

C

Yeah, it means I'm. Today, I tried to figure out. If there's any issue for uploading artifacts to the releases feature, I've been unable to find any so I, you know maybe they're there. All the probably are up just using different terms, but if you look for anything like upload artifacts from these artifacts with the DevOps release, label, etc, that I I can't find anything which really means it's they're using different terms, or it's not maybe plans, but you know neither is very promising for us at this particular point.

C

E

Could you check out the comment after the release evidence that I linked I asked.

B

Thomas, you add.

E

Release notes to get tags and I mean that box. That box is showing mean that you cannot catch stuff. It's like it's not only comments that you can attach right.

C

So those are just the the mark, don't upload, so you upload and then just add some link in the markdown. It's not like this physically separate thing. Where you can sort of query it, usually an API using this approach. We could do that we could attach building. You still have to sort of parse that upload URL out of the markdown, whereas what I was hoping for is that you just have say an API. You say Oh, given this, these release notes give me the artifacts and then you just get a list. Boop done and any.

D

Developers can change it later on I'm, not sure if it's developers or maintain everybody, it can be changed later.

E

Okay, so the reason why I'm kind of pushing hard back on having the JSON files so fYI, like if you recall for auto, deploy like we all agreed that those JSON files we we used was good enough for that time. What I'm trying to do now is find a bit of a more stable solution. We knew all of the problems that storing JSON files in the repository bring and one of the solutions here is not to get that dogfooding star.

E

That jar mentioned it's more about leveraging some of the features and if we don't have them building them for ourselves, because I don't want custom, tooling, I want to leverage what we have as much as possible because it adds overhead maintenance wise right. We call when do you recall, when Jason asked, storing the JSON files in git repositories causing causing like deployment failures, because the job would not be able to find or parse or whatever right, and that's what I'm trying to kind of avoid as much as possible. That's part: okay,.

D

Cool, we need something to add a custom Jason to the release. Evidence feature if you want to yeah so so.

C

Maybe I guess first that there would be to ask a whole herd name. The PM of release mentioned not or or its yeah.

E

Tomorrow, right.

C

E

C

E

Step there yeah.

C

That's her so I think the first step there might be just hey. You know you have any issues for uploading artifacts to release notes, because you know we couldn't find them and there okay, please prioritize that. If not, if the issues there I guess, we can do it kind of similar to what we do with deployments. Like do you right side, we can just leave for now.

C

The features have an API to upload stuff and get that it's good enough for now, because any UI we add, it's gonna, take like two three months for people to figure out how to visualize that.

C

So we basically do the same as with deployments we go and we build a API I, keep it simple and then it's like here's, a pile of follow-up issues, have fun I. Think.

E

That might be the approach. So, let's, let's finish this part, this topic with I'll go to speak with Jackie to see with the product. What we can achieve there and fall back here is: go down. The route of storing JSON files indicate repository if the time lines end up being like too long I'm fully aware this is blocking us from the migration in kubernetes, so I, don't want this. To take too much time is. Is that okay for everyone.

E

I, don't see any movement so I'd like some cue, whether this is agreeable or not yeah,.

C

So it's fine I hope.

A

It's okay, I just have concerns with how to interact with the stuff, so we could send the right stuff between release tools and our deployment mechanisms in the future. I think those are problems here to be solved. I think.

D

That reasons we should split the problem, no no I mean we. We don't need to change how many bars and everything right. In the same moment when we changed the way we truck. So we can just ride those five in the repo and we can do this with the API so that we don't touch yet so it's just our own API s and then we after we tag it is.

D

We have played all the sub components and in another time, in the future, we will just update omnibus and everything to fetch information from the central repository. But but this would solve us all the problem that we have in release tools, because release notes when you get notified back has to figure out from a tag coming from nowhere. What were the components involved in there and if it's already written down, we say. Ok, this was the chart version. We didn't have to have the way adults, charts sha-2.

D

The tagging mechanism that we have it in place now.

B

Just a question: are we also deciding on whether we're going to change the tag formats or is that a different discussion I think.

C

That will come sort of first level, probably to record this information using the existing tag, format and then I think changing the tag. Format is going to be fairly invasive since.

B

C

Have to change all the births with baby after change, the deployer have to change quite a bit in release tools, because now the input is going to be a much simpler tag and if I say all right, you know we have to actually get that info from here now and so for that it's gonna be a couple of steps. We can probably do that incrementally, like we can add the recording first from these tags, then I guess change it to support both all a new format and you know, drop the old format etc.

C

But it's gonna take a little while I think it probably in the order of a couple of weeks.

B

And just one last question: while everyone is here, what will this new project be named and what group will it be under.

B

F

B

Component component, it's.

C

So it's on tops released.

B

Released holes is under give aboard I think it'll, eventually change, but right you could.

C

Pay I think I would do Caleb work because get out commas you do for like get lot become specific stuff, and although we use it for kit like that, oh they're, so data itself is just no package. Information so gets get lap, org, slash releases or something like that or components.

C

Well, maybe just let's.

E

Not use, let's not use, components or versions to arbitrary, not I, don't the other things are not so at least DB meta.

B

Maybe like release better were yeah.

E

Something like that is fine, I'm, more inclined to push this under the group where, wherever release tools ends up. So if we end up deciding that github or sorry on ops release tools are going to be in a certain group. We should put it next to it right now, I'm more inclined to just say that will keep the state as it is and keep it in the same group.

B

I'm so tired of this stuff that it's like it's hard to make a decision. I, don't know I feel like whatever we choose. We're gonna, probably change it later of.

E

Course, that's the test technology job right.

E

What specific this do you mean because there.

B

Are the groups what's up good to put it under? Oh.

F

C

B

Will change right like- and this is something that shouldn't change well I, think.

C

That, like the group, is probably the least of the problems, because that's in in the code sense, that's just one line. You change so.

E

Should we just go on ops on ops, we don't have to follow what we have on comm. Really really really. We don't.

E

That we have a lot of inherited things from like history on github.com and we don't have to repeat those mistakes like the separation between get lab or get lab. Calm really really doesn't make sense right now for this company, so I'm saying that we obviously we don't have to make a decision right now, but we can make a decision if you want to announce so.

B

We can see but yeah we could put it under it, so we don't even use Capcom, but the laborious.

E

Have it completely separate release tools can be under that as well. All of our tooling, if you want to, we can put it under that.

E

E

So jar, I, wanna I, know that we are at time, but we are making very slow decisions, because these are hard problems. Your second point was they're related to which projects are. We tagging.

B

Think I guess I guess first, is we probably shouldn't change anything right now, so we'll continue to tag omnibus and we'll tag charts and that's it and I guess the the difficulty here is scarback is going to be like how we handle charts, only changes and how we handle omnibus. Only changes do we have to do we start off there just having to tag formats.

B

One is the simplified version which you use for charts and the current version, which is for omnibus, or do we do something different like I, really I, think I think we should take an incremental approach here. So maybe we have we comp in a simplified tag for charts.

B

Let me use the existing tag. Everything else I.

A

Think that is it's not a bad idea. I worry about what confusion that may introduce as we'll have tags with different information in them, I mean we already have a difference in our tag structure, because our helm charts have a different.

B

A

To what we do today, you know with 3.1 doubt whatever versus 12.9 dot, whatever we can't carry that same tag into the help chart as it stands today.

B

I, don't know I think, like we're gonna be slowly moving to a state where we're not extracting versions from the tag anymore. So really, we should just have a way to identify a tag as an auto deploy tag right and I.

A

Would do that some sort of uniqueness to it yeah and.

B

And and I think the yeah exactly so, which was probably timestamp, and perhaps we just add the string auto, deploy to the tag and include a timestamp. It's very generic. All our reg axes are just you know, look for auto, deploy and that's it that does simplify things, but to change it. For our current tag is going to be a little bit of work, it's not too bad. At least we don't have backboard so I. Could we only move forward, so I think we just have to update a couple projects or a few projects.

B

C

C

F

Maybe not the Jason, but something in the annotated tag. Message not protect itself like the message parsed that I thought.

B

About this idea, jokingly talked about storing JSON in there. The problem here is like what is the canonical project that holds the tag, because, right now we don't really have one outside of omnibus.

B

So it's like would release tools, then be tagged with the data or but all of the projects that get tagged with the data you know like or would be do, charts and omnibus, where you know I, think I think it's.

F

Like charts on the bus are kind of currently.

B

F

Right, you can't say the tag and Omnibus gets created in the tag in the chart, so.

C

I thinking it's like, where do we want to put Jason in the tack description or you say, releases feature? We've got to probably need to create text somewhere, because this releases feature relies on tags as far as I can tell. So.

C

If we have this components metadata whatever repo the idea Adam buying, is you basically I just want to commit just as a VP and I would just be tagged that every time and the tack is you know whatever the version is we deployed, and then we associate all the data to they aware that it's in the description as artifacts or something else, it basically means you end up with. Let's say: 10,000 tags all on the same commute, but as far as I know it doesn't care about that. So should be quoted. Well, fine.

C

Why would they be on the same commit? So we don't have to create new commits? Basically mmm it's because otherwise she had up have to create like a dummy commit. You know to change something, but as far as I know at least our API and get itself, you can just create a million tax. Almost same commute. Yeah, that's fine.

E

Basically, that would allow us to like, regardless of whether is like this project, let's call it release DB, whether we store JSON files in it or not, could become our single source of truth when it comes to all things tags, and this could allow us to also think about how are we going to tag things in other projects like omnibus charts, get lab components? I, don't know whether it's necessary to go that deep. But theoretically, if we have just the specific syntax in this new project, we can derive all of the things in different projects.

E

F

One of the things we keep mentioning is like a repository of you know, files that are the kondañña versions at each stage, but we only need a single file and then you update it and tag it, and if you want to see the history of you just go to that tag or the commute history for that file right, you don't need one file for each release. Yeah.

B

That's that's true. We can do it that way like instead of yeah, you could just tag a file and then something external another project could just fetch the version you know of that file. Yeah.

F

B

You can do you can.

F

Do blob at any yeah.

C

F

Gonna be an issue like.

C

Technically, it's possible to have deployments running in parallel, like you can have a staging deploy, that's running. Well, there is a Canario deployments and so kind of depending on where, in that pipeline, we create this data. You may end up with two jobs updating same as so. Let's say you have a file simply called let's say version blue Jason, and it just contains a version details of the latest deploy if two deployments come in, they can overwrite each other, and this.

B

C

We actually had with the deployer Jason we're under certain conditions. The order of deployments would end up being different because it would basically take the whole file post in and the other one would overwrite it. So we.

F

Have we ended up operating it.

C

By environment I think yeah, so we had one directory per environment.

C

If we use sort of a current version approach, we have to do that split again per environments, but technically there's nothing. Stopping us from running multiple deployments in the same environment like I.

B

Don't understand why? Because we only tag once it's not per environment,.

C

No, so what we had at least in the deployer was you would have, for example, deploy to you kick off to canary startup and, as somebody say, hey, let's also deploy to staging. If that staging deploy happens to be basically if they both have to reach the tracking stage. At the same point, just whoever comes.

B

C

B

I understand that, but what we're talking about here are the mapping of like the marketing release to the component versions, which that only happens once it only happens when we run the tagging. Job in release tools doesn't happen.

C

So just component info, we would also update it for all the deploys exam, because we need the date thanks.

B

I, don't think so like where it's deployed to is another thing like this is just I thought. The only thing we're talking about is this is the tag, and these are the component versions for that tag and then right once.

G

Environment, that's.

B

The point yeah, what what that environment yeah? What what environment has that deploy? That's tracked in somewhere else, right.

C

E

C

E

The discussion from having one file, which will which will contain all of this information right mm-hmm.

E

So if even if we create this new tag, if it starts updating that file, because there might be like two things happening at the same times, two tags being created at the same time, they could clash by for updating that specific one file. I think that's where we are coming from right. Yeah.

C

So, first security release. We would actually have taken multiple things, but in all cases you can scope that per environment function, whatever I think. My point was more that if, if we use this approach, let's say for a month forget about a conflict, we basically try to get tagged somewhere for the version we associate. All the you know metadata with that, if we only use that for stable releases, 2.0.1, etc.

C

We end up with this weird split in release tools where we still for order deploys, have to handle these weird order, deploy versions and I, say: oh, it's an auto boy. So that way, I see you do all these steps and then at the tech resort. Oh wait at ecklie's. Now we suddenly have to go to this release database repo get our data there, but I was sort of steering towards us. We basically throw a tease over the foyers who say no that release database, that's where we always go for figure out.

C

This is an older boy. What's ah what's the you know, give early version etc, and in that setup you can have multiple deployments. Updating these or creating these tags sort of in parallel rights where so.

B

I some point: student version doesn't work.

C

C

Well, I think, there's a simple support, simplest least problematic approach is we get whatever version were deploying tech and whatever for that? We create a tag, and this would be a 12, a 1-1 hours when the older deploy week number or something like that, and you put all the metadata in there. So you know long term, you end up with repo. You know 10,000 text whatever, but it means at any given point you could sell for this version.

C

This was all the data and we can then release those creates that, but it also feeds it back into itself. So then you can use it to record deployments, create QA issues etc.

B

I'm not sure if I and kind of like I'm not sure it would be better having a tag with meta information in the tag or having files or having one file or have multiple files. I think I can see I.

C

B

Cons to all so.

C

I, don't think, there's a point in tagging. If you store in files because then yeah right, we wouldn't use the text. We just comes.

F

Out the oil yeah.

C

Exactly so, I think you know the approach there, so you know. Let's say we go to the release management group and they say oh yeah, we can do that in a penalty bond release and then we would have human API to upload artifacts. You know at that point we just create tags and we tag some dummy commit whatever the last one is, which is just you know we or something and all the info stare.

C

If that doesn't work, if it's too long to complicate whatever I think we just go for files, we're per I, guess perversion: we have a directory or one file depending a bit on how future-proof we want it to be, and then in there we store the omnibus, whatever shots, etc. I think a directory perversion with a JSON file in it might be a little more future proof in case you wanna at this case, where any future on say. Oh, we have this.

C

You know completely different piece of information that we also want to store there, but practical speaking doesn't really matter like the the code would more or less be the same anyway.

E

So you're I got really completely distracted with some information that was coming. My way did you did you just explain, basically that we can just use this one project, regardless of which way we decided to go? Yes,.

C

So we create a service, DB project yeah and ideally we use Felice feature, so we could sort of dog food. Yes,.

E

Yeah yeah, but we don't have to like. We can start with this right now and like decide and move unlock ourselves and then switch to the features right like that. Yes,.

C

So sorry I got distracted. No, so if the release group says no tis, this is gonna. Take three months. We can say you know what yeah we'll just create a folder call it releases or something we get a bunch of JSON files off. We go and we'll have the same problems as to deploy which isn't files, but we kind of know those problems and I think it. It has the least problems of all the ideas we we can come up with Oh.

E

No, so that that's that sounds fine to me. Does this answer the question, though, which project are we tagging? It's gonna, be that project and yeah.

C

It will be like a dedicated project. Okay,.

E

Vision, sort.

B

Of except we also have to tag omnibus still, so we probably would also tag on the bus with the same tag, because we rely on tag pipelines, cromnibus.

G

A name is the tag charts.

B

As well so we would tag charts, omnibus and this new project, and then the meta information would be either in the tag or then you'd have one file or whatever we do like. So.

C

As a matter, I think that, like in only a bit of scale up all these source projects, we we can create tax and you know technically, we should, for you know pet releases or whatever, but they won't contain all the shah's or whatever, because it's not particularly useful there, it's more Soviet user phasing information. This separate repo would have like a pile of metadata that we only use for release tools and whatever stuff.

E

E

We are way over time, but do we want to continue through the rest, I.

B

Guess, I guess I'm kind of curious what the next steps will be. It sounds like we're probably going to do this for Auto deploy first, focusing on auto deploy. First before we focus on official releases right, yes and who's going to be driving this primarily skarbek someone else.

C

And I can take the the vehicle side of things like I've been knee-deep in the deployment stuff there anyway, I think I release tolls. It would be at least for this initial setup. It wouldn't actually be that much work, because we have all the data we have it sort of torn apart at various places because we need it separately.

C

So it's more of us a matter and figure out sort of where we hook in and that's it at this point you know creative JSON file with this done.

E

That sounds good to me. Let's start with that, I think, let's start with that, and let's see how far along we get and we can reconvene to handle things once we have more information. That's okay,.

B

Yeah I think so it feels like there's. A lot of coordination needs to happen here. Maybe we should do another fastboot.

A

Yes, I'm on board with this I mean.

C

We have the summit coming up.

B

Now, honestly, like it is gonna, be highly coordinated. Cuz, you know yeah just to get everything everything all the pieces working together. It's a lot of moving parts, yeah.

C

I think the benefit here is, we can do this incrementally, like we don't need to turn astray, there's a first implementation. We can, for example, just for court, the e, and only this and get leashes, and maybe you know whether it's basically eating four. We already have we just spit it out in Jason, and that is that that's fairly a fairly small amount of work. All things considered, of course, feeding that into other systems. It's gonna be more difficult, but I think we can all do that sort of in parallel.

C

Incrementally we don't have this case, we say okay at this point, everything needs to be done.

E

Cool sounds good to me. I think it's a good step. I have one item for myself, but it's not blocking.

E

Your heel you'll create the issues from this discussion. Skarbek you'll upload this somewhere or share this because I think we shared quite a lot of information here that we didn't really capture. So it would be useful to have it handy to reference cool all right, no I! Guess thanks. Everyone.