GitLab Code Review Weekly Workshop, 11 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Code Review Weekly Workshop - Aug 11, 2023

Description

In this session we talk about code review!

00:00 - Intro
00:35 - Sometimes reviewing in the terminal is easier
05:10 - A thoughtful review question on test coverage
09:45 - Enforcing responsibilities and avoiding leaky abstractions
16:12 - Question about punting on a question to maintainers
25:30 - Pair reviewing on some dependency updates

A

Thanks for hopping on the code review, weekly, Workshop, oh and by the way when I was um finding the recording for last week, I came across the playlist, and this all.

B

A

Last August, so this has been going on for a year which I couldn't believe that it's already been a year that we've been doing this, which there you go uh all right um well, I, had something I wanted to share uh so I'm gonna share. My screen and I was gonna hop into this Mr, um which Miguel put together, uh which I thought I had approved and merged, but I guess not: okay, either way, um it's removing a whole bunch of unused data test, IDs a whole bunch from 102 files.

A

um But it's like hey. You know if we can validate for one like if all the pipelines run, these only ever used some tests. So if all the pipelines run successfully should be good um and uh yeah so, but how do I review something like this?

A

uh Well, one file at a time helps, but I was gonna share with you um an easier way to do this. um That might be an easier view into the problem.

A

So I had this checked out and I found myself clicking at this one file at a time and it kind of takes a long time when you do it that way, um because I gotta click one file at a time and so I know what every line that changes back and forth I know what it should look like um and I don't need all of those contacts.

A

I just need to look at. Did we get rid of a data text? Id thing? That's that's all it really concerned about. So it can be easier, sometimes to actually look at the diff in the terminal and set this unified diff parameter with zero context so that it looks like that's and then I can just scroll through it's like yeah. We got rid of test ID yeah. We got rid of a data test ID, it's like yeah.

A

We got rid of data testing and this could just be make it a little faster as I review things to see this very compressed View. Sometimes, when we've gotten rid of um lines like this we've, even uh I, think you can get rid of all the like file, headers and stuff and I've done something to just verify. We're only removing lines that look like this. That's the only thing we I can kind of care about so uh yeah. Sometimes looking at the Mr through different perspectives can help you be more efficient when reviewing it.

A

So this little parameter on the diff thing, uh this Dash capital. U zero, helps me, do the unified diff with zero context and was helpful at reviewing the SMR, which I somehow neglected to merge. uh Oh no, oh I enabled an automatic merge. Oh, but something may have happened. Oh a danger error, oh I, just okay! Well, there we go! That was my thing. I wanted to share.

A

Does anyone have anything that they would like to any any topics that came up while reviewing code, questions or interesting things that you've learned? That would be fuel, interesting knowledge sharing for code review.

B

It's it's not really related to GitHub reviews, because I don't do many, but I really find it when there are so big, like 100, plus, even 20, plus files to to just use the uh you know that there are two ways to show the diffs on the Mr Page, the the single page, one where they're all one under the other and the the single file I usually switch over to the single file and use the keyboard shortcuts to switch between those to have a quick view.

A

That's a good point: um yeah. They didn't come up that that uh I didn't think about that and yeah. That could be helpful too. That is a good point.

C

I maybe have a really quick bite as if an um I was working on my mind, which uh somebody reviewed and that review asked me a question which I am a very, very big fan of. So, if you're folks curious, let me just uh grab the screen, so um it doesn't matter too much for now what this MRI actually does.

C

But let me see if I can quickly find it there we go um so what I did is I removed and shared um function, util method, one of those and I just did it that that was about it and the pipe that was green and um I. Yeah went to the pub basically um and Peyton then came along was like well, usually we speak about test gaps when we add stuff- and he was like we're- not removing any specs from this.

C

This is this thing's still running, which I kind of really loved as if in well. Maybe we should speak about test caves even when we're removing them or even when we, when we identified them and we're already past it, um it kind of turned out to be good as if and the thing is rather trivial and we are testing the the usage of it.

C

So the answer was kind of well we're, probably okay with you, but um I was a big fan of the approach as if and something still out here so um just to have. It said that might be something to to keep an eye out if we're just removing things and everything still working as expected, maybe be suspicious about it.

D

So insuspicious you mean at that point. If it was lacking test code coverage, then explain maybe give context as to how you verified it manually or something like that. That.

C

Would be yes very much so that would be one approach and, on the other hand, like the test gaps, don't come alone many times it would be like what is going on here. What util file are we speaking of? Did we remove it completely? Are they still leftovers? Are those coverage like basically check surroundings? Maybe that might be something where there could be could be. Some potential findings still open.

A

Yeah, that's that's interesting. So did you have to create an MR to add the test coverage so that you could remove it in that Mr I'm? Joking? What.

C

Has been nice, though, that.

A

Would have that's that's what the 10x engineer would have done. It's like! Oh we're, removing this code, but it's not tested so I had to test for it. Okay, now we can remove all of it. Yeah I.

B

Actually, I actually had to do something similar a couple of weeks ago when I, oh yeah. Basically, the fox button Forks button on the project. Page I migrated that over to a view component, but the fork button has some intricate logic to decide whether or not it's disabled or it's a link to the forks page or to the new Fork page yeah that stuff and that was not tested. So I wrote I, had to write some specs for the old code to make sure that the new one worked.

A

And just saying was it: was it features specs? So it's the same specs for that ran on both.

B

A

B

A

Big deal uh yeah, that's interesting! That is interesting. um I've heard it called like um I have a really really great software engineering book. I highly recommend to everybody is uh working effectively with Legacy code.

A

uh It's really helped me out at gitlab a lot, um but it's one of the things talks. All about is like doing test hard test hardening and test harnesses. Before making changes. Gotta try to like pen things down with tests, then you can make your change and what.

E

A

There Marco just reminded me of that of that book. It's like yeah, it's a good good call.

A

um I've got uh another thing that came to my mind. um Let me.

A

Let me share this. um Let me share this I called I titled, this idea of keeping an eye on the responsibility of the module or whatever you're reviewing. um So here is an MR. It was um not big and it was pretty straightforward was what was going on, um but I left the question because I saw uh so we have like some sort of create form.

A

um Let me see if I can like open up a whole old version of the deaf. We have like some sort of form. That creates a thing when we finish creating the thing whether it failed or passed. We then were emitting hey time to hide me and I thought. Well, that's weird! If it fails like I imagine the user would want to like retry the action and not just we'd, only just hide the form if it failed.

A

So that was my original question, but then I kind of just mentioned as a side as like, and maybe we should just call it hide because from this context, the only things we were admitting we had two events. We were emitting, we were emitting reload and we were emitting hide ad form, and so, from my perspective, it's like well, we are the four let's just submit when we need to hide ourselves.

A

We don't have to call ourselves to add um so then uh um the uh contributor who I now who's also like our product designer so like working on a whole bunch of ux paper cuts, but he's like doing a lot of code too. So it's so he's kind of got his foot talk talk about them being like a full stack engineer. This is like full stack like augmented one level. It's like full stack and doing the product design, stuff Islamic Sun, uh um but so the question was well would renaming it to hide.

A

Make sense, because we want to hide the ad form and so I then realized from the scope that we're at I was like. Oh the way we're naming things was like we were actually trying to tell the parents what the parent needed to dip. So that's how the events were named rather than the child admitting its events and states and the parent decides. What to do.

A

um Reload was like telling the parent hey I'm done now. You need to reload parent or hey I'm done now. You need to hide me parent and that's a very subtle uh abstraction breakage, where children shouldn't tell parents what to do as a parent, I completely concur uh anyways, um so the suggestion was: oh, it shouldn't be confusing. We should because we're just listening just to this form, we can call it hide, but now that I looked at it we. Why are we even telling the parent that the parent needs to hide me?

A

um So instead is like the right event. Names for this thing was success, I finished or cancel I'm being canceled, and then the parent would then handle that, and so what that looks like is rather than the parent consuming this from High Dot form and that maps to my function, hide ad form or reload.

A

um I. Just listened to success and canceled and success happens to hide and do a Reload. But that's me as the parents be concerned about, so it's very easy for um when the abstraction breaks for then hide ad form to not actually hide the form or for reload to not actually cause a Reload of stuff. So uh even though things were still functional, um keeping the boundary of responsibilities goes a long way and so I kind of have to judge the fatigue of an MR.

A

Based on what I'm, gonna you're like okay.

E

A

We need to take care of this beforehand. If, if we're at, like 100 plus comments, these might become more follow-ups but yeah.

D

That's interesting now, on the specific case, something like this is like maybe hard to see if you're too close to the code, meaning like it, might be easier for a reviewer to see this uh than the actual person writing the code because they feel like they're all in the form, and it feels like you know what I mean yeah 100, maybe that abstraction started in the form and it broke out into another component. And at that point you know it like kind of made a lot of sense and then.

A

Yeah and that's one of the best things we could do with code review is just provide a collaborative perspective of oh hey. It looks like there's coupling here because yeah when you're, oh, my gosh, that happens to everybody uh being too close to the code. It's a good point.

A

I'm I'm pausing for a fact: Terry, you look like your window is open, but the wind is blowing towards you. I.

F

E

F

Ac up when my kids aren't here, because I don't want.

E

F

um Then I get hot. So it's for my fan on.

A

That's Brave: do you just angle the MacBook in such a way that the fans blow at you yeah.

F

That would be great. That would be hot I. Just have like a giant like a desk fan. That's nice.

E

F

um Yeah they also broke something from with my camera, so you're, looking at me from my laptop.

A

Yeah I did I recognized it's the same, the same location but I recognize it was different. Yeah.

F

um You've been missing me to be able to come.

E

A

That happens, I know it's like uh the everybody's availability. There's there's probably some pattern to it, but I know it's like okay, there's, like a couple weeks almost nobody's here and then there's some days, there's loads of people here, um yeah about to look like you're, adding something.

D

Yeah so maybe best if I shared it so like this is an MRI, I authored, um and so, as we reply to a con, a a comment from a reviewer and my Approach, the the thing the whatever was being discussed is in material.

D

um It's more about was I being lazy, because what I did was um I said I kind of agree with you, but I, don't know and I kind of feel like after I wrote that and then you know like five minutes later. I'm, like maybe I, should have went to slack and done the legwork to ask others opinions on this, because it seems like something that was like not documented. That probably could have been. But you know the knowledge was out there somewhere.

D

um So do you think I was being lazy in this case, or was this the right path to take to put it back and say, like you know, um maybe we should pass the the maintainer.

E

A

I, don't know what do you all think? Does anyone want to be the first person to tell Doug they were? He was lazy.

F

I, don't think it's lazy, I mean I, usually try to go by, especially when the when um I I do reviews for it and I don't want to be a maintainer I I have to go, buy what it says in the docks and so I feel like. If it's not specified in the docs, then maybe it's up to the author. I mean man, I mean I. Guess you could have asked um yeah I mean these removals are already like multiple step processes, right yeah, like the ignore column and this, and that.

D

I feel like it was an unknown. You know it's like it made sense to me and I gave my contents to the context in the reply when it made sense but I'm like I, don't know, maybe you know I'm kind of like not certain if I'm breaking you know like potentially breaking something here, but you know my fear of leaving it and being lazy like this. Is that I knew perhaps due diligence could have been more and now I'm relying on the maintainer to do that due diligence? Is that fair.

A

I I do that all the time.

D

Even if you are a maintainer, let's put that one right.

A

Well, I um I think we don't here's something to avoid.

A

We want to avoid people feeling like Mrs, have to be very, very, very polished before they come to a maintain and we want to encourage submitting an MR at any state. It's up and so to me. I feel like at any state it's at.

A

If it's not obvious, what should happen is like I, don't know, let's, let's get more people, let's get more eyes, that's totally fine, and if the maintainer at the end of the day, that's like well I'm I'm, the one that's going to merge this and I say we should do it this way. It's like okay. Let's do it that way, like that's I I. Do that all the way, all the time where it's like I.

E

A

Let's, let's get someone else how's this opinion because, probably because I've gone like because one possible outcome is you do it this way and the maintainer says: why did you do everything? Why didn't you just do this and then so um I think looping in more people and deferring some of those commitments can make you maximally efficient.

D

It's a good point, I. Think one thing here, this points out is maybe there's a lack in um there's a gap in uh um documentation, so I should have probably opened up a follow-up here to um look at enhancing and then I'll get a definitive documentation.

E

D

F

Yeah no I think that would be good. I see the people opening those for the I mean the documentation for reviewing database is like ever changing yeah. um At least it feels like I, literally open it every time. I do an NMR, because I'm like I, don't want to rely upon what I thought the rules were. If.

A

F

Have been updated.

A

That's that's a good point that this almost sounds like something that uh danger could provide of like in the Mr. Oh there's such a database. Here's the database documentation, it's been last updated here, like I kind of think, it'd be really helpful.

A

um What would be lazy is, if, like this is the nth time. You've received you've done this task and the conclusion has been the same every time, but that would be lazy. uh I think I think I've kind of seen, glimpses of that when I'm reviewing code and it's like- oh well, we need to add unit tests to a thing like I said in your last five Mrs.

C

A

Yeah good question, though: I think it's a good question. Yeah.

D

And I'm with Terry there that I will I never want to be a um a database maintainer because I just don't think I could ever be qualified to be an atom or one of those people who I have total faith in you know when they merge it. Oh.

F

Yeah even reading through the docs I'm like clearly this follows what the documentation says and then one of the maintainers will come along and be like here's, the exacts that are the ones that I was looking at and I misinterpreted them or yeah, especially when it comes to batching through large amounts of records. That stuff is very complicated, yeah.

D

So I do feel like database reviews. Database changes can be some of the most complex, Hard Review things, because it's there's no exact science to it. A lot it's like well in this condition. Yes, in this condition, no well sometimes sometimes not you.

E

A

Yeah and it's I guess those those experts have so much experience that they can. They can see how A change is going to play out at scale, possibly like from you know: mistakes made too but yeah. Whatever we made again, it's tough.

F

um That's why I think our database guys are always changing because, like we ran into issues with like the Common Table Expressions, that cause like major production.

E

F

One big one that I think of that now they're like oh, we don't do that anymore, and so it's like actively called out in the documentation. Yeah, that's interesting.

A

Yeah well I think so we don't have any more items on code review, questions, Show and Tell. Unless someone wants to drop in the thought that is itching to come out. No.

F

I'm really excited for what you have listed next, because I'm not sure what happened. But dependency bot has been very active and repost that I'm a maintainer on lately and it's causing me a lot of stress.

A

Yeah yeah I have, for some reason a bunch of science to me. So I was like okay, we can just uh go through some of these. One of them is more interesting than others, um but uh let's check it out. um So let me get to it close. Some things.

A

Here we go sharing, screen, uh I was building Ikea furniture last night uh and.

F

It's still alive tell the tale I.

A

Know- uh and it was all successful, but it took way longer than I was anticipating. I was up late, trying to put in the cabinet things all.

B

Right, that's only for the for the first one. Then you know how to do it.

A

That's the other thing is, it does usually take me like whenever I'm doing something new it'll I the first time is gonna, be rough I've.

E

A

The second or third time's good, but when it comes to building Furniture, you didn't buy two of them.

F

That we we put together an IKEA bed, my husband and I and I was like we might be okay to be married because we put it together, three or four times before it was correct, still married. So it's.

A

Not I did um I I did do it backwards in the middle of it. I had to take it all apart and do yes, that's I know yeah.

E

A

um Okay, so this is targeting gitlab UI and is updating node um at a patch version, so it should be fine. Thankfully, there's cool uh changelogs here and it looks like there's notable uh security fixes.

A

All the pipelines pass. This is a patch version, so if I was going to over engineer this dependency update, I could probably look for something like node CVS. Just for that one of like are we doing new vulnerabilities or whatever, but I think this? Is this just got released? I, don't think we'd be able to find anything. Oh, this is for the types package. uh Here's.

E

A

Releases but I think it's gonna be too early to tell for anything like that and pipelines pass I think we're good. So.

F

I have a question for the gitlab UI project is how does this fit into the ecosystem of gitlab? At what point is this used.

A

That's a great question: um does anyone want to answer it while I, while I jump to the answer.

C

I'll give it a shot, at least so um it is our view component um library or repository at the end of the day. So the thing is consumed via an npm package in our gitlab main reposit repository like the monolith, I, don't think we're, potentially we're consuming is um elsewhere as well. So it is our component Library. Basically, so it is a standalone project that does include all the components that we are using, whether there are participate UI and that is basically a different Foundation teams is working on. The designers have agreed on that.

C

These are good to go um so yeah. As a client-side engineer, these are the tools that you or components that you kind of take and just put them together and you're good to go and.

D

To add to that, it's also all the CSS styling and stuff yeah.

F

Yeah, um okay, so you're.

E

Not updating the project.

D

So I just want to make clear like it's built upon uh bootstrap, so it's basically extension of bootstrap right now. It's like our coloring on top of it, so we could like swap it out out bootstrap and not be affected. uh You know in gitlab by doing that.

F

um I guess I'm asking because is there any responsibility for you to test this in some sort of git lab context, like does that version in git lab get updated by someone.

A

um Yes uh and yes, um it gets updated automatically by renovate bot, which uh it's one of our one of our top contributors um right.

F

Like the renovate right.

A

Above Marco there's Marco and then there's pitlab renovate bot.

F

We'll update this and then the renovate bot will be like. Oh hey, gitlab. This thing is now updated, so you should roll it in here and that's how okay yeah.

A

So, um based on the commits that uh good Merchant domain, we will automatically generate a new version of like. Is there a Breaking change and that's going to be a new major version or whatever is going on um once a new npm owns a new gitlab UI version, then renovate bot picks that up and shoves it into all the projects that are using gitlab, UI uh orb crates Mrs similar to this, but and so when a user.

A

When a code Reviewer is reviewing a gitlab UI update, they should probably look at the change log and see oh, how risky is this update or not? And if it's like? Oh we're, touching the button component in a significant way, it's like well buttons are used everywhere in gitlab. I probably should just do a quick double check, but you.

E

Can also from here.

A

There's a pipeline that could be run. Oh, where is it.

A

Can I run it?

A

This is the reason this must not be showing up is because it's not actually touching any code. I think this is touching this tool versions file, but there's a pipeline I can run to create an integration branch on the main gitlab project for this Mr, so that I could do testing of a change in integration with gitlab.

F

That's cool yeah.

E

F

Asking this because I some of the projects that I use are I wonder about like okay, if it's like a tiny little update like this, maybe I'm more like oh, it's, okay, but we just had one that was like upgrade get a Lee from v15 to V16 so like that. One to me feels like maybe some tests in context of gitlab before merging this, because, like all of our tests passed in the project but um I, don't yeah.

A

Because coverage might not be there right well in this package, also like um this package consumes like gitlab, svgs and other packages and then yeah our internal packages. We want to treat them like external dependencies and make sure hey.

A

Is this going to fit well in this context, and um it's worth doing that validation I feel like it's always worth with dependency updates, don't waste a lot of time um and we spent way more time than it was been on the simar just talking about which is cool, um but the main thing I have, rather than like, oh or the pipeline's good good we're good to go.

A

My big question is: what is the worst thing that could happen and in this situation the worst thing I can think of, because this node is from Tool versions, so this is just for. Developers would be like if this node has like some crazy, huge vulnerability and the fact that developers would be using this on their machines. That's or if this has some huge buds that when we build our assets you, but we don't build them using this using tool versions. Node, that comes from the docker containers of the CI pipeline.

A

So to me it's only like only developer machines are kind of effective with this and I'm pretty sure it's not a huge vulnerability, so it's like yeah. This is fun.

E

You mentioned the.

D

Vulnerability part- and you said it was too new now to me that says like well, maybe it's doing it too soon, then you.

A

Look I, I, guess, there's different schools, if not so I'm, very conservative about like I, don't want to update things. Security keeps telling me to update Mac version, but you know what who's to say that the Mac version they want me to update doesn't have security issues, but here's the thing that I was. You know enlightened upon, and my early get lab days of. Why we do it this way.

A

Is it probably does, but we don't know them yet these ones we do know so we gotta update now, and so it is an arms race of like yeah. You just got to keep things updated and that's kind of the the approach to security when it comes to dependencies that we adopt it's trying to trying to stay as up to date as possible. Keeps you actually the most secure, even though sometimes I'm easy I do like a quick pivot. If it's like whoa that one wasn't good.

B

And you can always wear that back if there's something big that comes out.

A

Yeah yeah um yeah in the past I've I've, like strong I've, suggested like hey. Maybe we should wait for a version to settle for like a year before, but that doesn't normally go out but go over very well.

A

That's a good question.

D

Cves are like you know: I guess it did might be a little different conversation if there weren't cves that were being resolved by this as well. I guess, maybe.

E

A

Yeah but uh yeah.

E

And and I don't know and.

A

So but there have been times when um I haven't merged a version, because I went upstream and I saw well there. This is actually there's actually open issues for this version that it's broken and they're working on fixing it, and it's like. Okay in the meantime, let's just not merge this, so I've I've done that before, but so I don't think it's like a. We always have to upgrade but yeah. Clearly based on the change logs, like yeah, we probably should but.

A

Yeah, these don't seem like very critical. Well, I guess this says: hi policies can be bypassed. I'm, not gonna, I'm, not gonna dive into it. This this is a rabbit hole. I'll, get distracted, um it's cool! It shows these commits.

A

Okay, do you want to try looking at another dependency, update, I? Think this one? Let's get to me, uh this version of node is only is Dev environments, uh School versions.

A

It changes, see minimal and helpful.

A

Approving starting marriage.

A

So one of the things I've started doing is I. Do leave like a justification when I'm merging a dependency update of like, and even if it's just like hey this is a Dev dependency and the changes are trivial. I was like I'll leave that kind of justification.

A

um Okay, I'm, going to add it to the merge train.

D

Oh I got you into that pattern of uh providing the justification. I've seen it on trainee maintainers uh approvals more than most. But what got you into the.

A

um A lot of it is uh paranoia um that I have in my head a what's the worst thing that can happen, and it's like okay, I've thought of that. This is why I think we're okay and I've just gotta hype it out and do it so dependency updates. Make me concerned because it's like this, could it's very e? It's it's seems really small, but I mean it's on us.

B

That we gotta verify.

A

That it's gonna work and things can break with dependency updates, so I try to leave a justification that I kind of looked into it.

A

um Okay, oh, we were just talking about gitlab, UI updates, so here's a separate package, the status page- um and it just has a patch update, let's check out the release, notes.

A

Okay, so it looks like GL collapsible list box is now correctly handling something so that's cool. uh If I was feeling extra paranoid, my question would be well.

A

Does this project even use GL, collapsible, listbox and like was it dependent on the buggy Behavior.

A

But I'm pretty certain it doesn't these smaller projects don't be used. They usually use just a very small subset of our kit lab components, but we can check it out. We can do the whole exercise of checking it out if we want to what do you think?

A

That's what we're all here to do right, we're all here to over engineer these merge request, reviews.

A

A

D

Now won't the review pipeline shouldn't have started an app inside the Mr that you could just go to or.

A

Not um possibly I am wanting to just do like a code wide search. That's that's I'm kind of looking for that right um for anything, that's collapsible response, but nope, it doesn't look like it. We have. A number of this is the full Gambit of our gitlab UI Imports and just contains buttons and stuff like that. So yeah, this is pretty straightforward. I then, when I'm feeling extra paranoid is like okay, you said you updated this version. Did you really do that dependency? Bot? Okay, the robots are still doing what they said. They do.

A

uh Ben I'm, like Yep, this dependency update, looks good to me. uh Change is a patch to a component that is unused and now.

D

If I were being like super paranoid here, I would probably say: don't trust the release message and go into the release and see what it.

A

Actually I know I, know, I know, don't no I know I, know, I, know.

A

And but it's it's cool that enlists these commits here so like we can jump straight to the commit and see the file changes.

A

Oh oh, wait, yes, and so I will I will actually jump into this link and view the change of the actual package, and that gives me another like um it gives me another perspective of like oh yeah. Did we actually change what we expected to change and so I see a lot of list box?

A

There's a disclosure drop down item change, doing something through wrapper class right and then there's these tokens. Css I go back to status, page I, don't even think we're using.

A

Yeah yeah we're good, but yeah. That's a good point. I I I forgot kind of forgot about that, but yeah.

A

Proving um starting right.

A

Approve, we do not have merged trains here, so I'm going to run a pipeline.

A

All right set to Auto merge cool all right, we're getting things done. uh This might be interesting. Babble has a patch update, it's a lot of just patch updates, so these two I've done. This is one. um Let me pause the Babylon, because that's I think it's going to be pretty trivial. I'm, going to show you this one that I've um that I've been I've procrastinated on.

A

So uh this is um updating, es, build and the gitlab vs code extension project. So this is our official vs code extension that we maintain and Es build, which is used as the JavaScript bundler from minor version 18 to minor version 19.

A

right at the top of the change log. This release deliberately contains backwards and compatible changes. Like oh sounds like more than a minor version and I guess it happens when you're in zero major version land, uh so I was doing some like breaking changes um and then it's like, oh and we also haven't updated since these other 18 patches as well. So it's like, oh a number of things could actually change here and so es builds is a Dev dependency.

A

um But I'm still thinking like what's the worst thing that could happen with a Dev dependency like es, build.

E

D

Compilation because it's not working locally yeah.

A

Compilation is not working or compilation works, but is buggy like what, if it's actually produces something bad.

A

So that's makes me nervous about like webpack updates and other things like that is like okay. These are Dev dependencies, but they produce they're critical in producing the production code, so I kind of want to verify I kind of want to verify the production code. So I could do this. One of two ways could run a smoke test manually.

A

It starts, nothing is on fire and things kind of work or the the the paranoid idea that I had uh was um running a.

B

A

Between the es, build 18 es, build 19, built and saying that anything actually change here, I don't know: do you want to try running that diff together, all right? uh We got some time. We could do this.

D

um One question here like a lot of these thoughts that you're having I think feel like things that like could be automated in the pipeline- maybe not the last one, because it's very specific and I don't know the ROI on that, but the first one about like the smoke test to see if we were like this feels like that could be like a CI job.

A

Yep I think I think they're I think there probably is one so to me. Yeah I think you're right for these I time box myself. So this is why, like I started this, but it's like okay I wasn't able to do this little task so I just moving on so I for this kind of stuff, I gotta time box myself when I say I, gotta smoke tested I'm spending five minutes max on this, and more and I have a timer set so that I don't get distracted um to do that.

A

But yeah I mean looking for the automation.

A

Opportunities is a really good point and maybe to some extent is like. If we can really trust our automation, could we just merge patch updates? You know directly without any oversight.

D

Right I think we're like almost a continuous deployment, but we got this one little step here. That's not that's making it not that.

A

Yeah but I mean at the same time it's like I, don't mind doing little smoke. Tests and dependency updates do make me nervous people, don't always follow semantic versioning correctly, I sure don't so it's you know um the first time you get burned by like a third party dependency and you realize, oh, you all are not like you know the post office and are super real, not even like the post office is super reliable. So it's yeah.

D

It may be one of those things like each change has a different type of validation, I've been in scenarios before, where I'm like QA, you know the QA. You know their job. Tell me what you're doing manually, so we can automate it they're like no, it's all different, depending on the release. I'm like you.

E

A

Yeah yeah, and that's that is interesting too, um but yeah I think that there I think there are things, though, that can some things that can't be audited like improved even like I'm doing this manual checklist in my head, but like maybe, why isn't that shown up in EMR of like these are the worst things that can happen or any of these relevant and I? Don't have to think about it? Maybe that's. Just that's. Checklists are kind of one form of automation.

D

Yeah some would say: that's the first step to get to automation, yeah, exactly documented.

A

Okay, so I'm here uh to get I'm gonna um all right, I'm on the latest main, so I'm gonna produce the main output of this project, which is oh gosh I. Have this big? Okay? um The main output of this project is comes from the.

A

Where does it come from must come from package tests uh yeah? This thing that gets built this bsix, which is actually a zip file, so I'm going to look at the um job description for package test to see what command I can run locally to.

E

A

I need to go to the CI file.

A

Package release package tests, extends.package, not package, npm, run package sweet, that's all we got to do all right.

A

um So let me first run npm run clean, I'm, pretty sure, there's a clean job to just clean everything up, but then I'm going to run npm run. Maybe I should run npm install.

B

Don't you need also npm CI.

A

Maybe I don't really know what npmci does and it sounds like a CI specific thing.

B

A

Let me try it, but it says to do it yeah you want to do it. Let's do it if.

B

That sets up some environment variables. Then you run back at the word.

A

Oh, it looks like oh yeah, it looks like something see it did the install again. That's interesting I wonder if it stands for clean and stall that I.

E

A

Doesn't because that that would be confusing.

A

All right, let's run package, this.

E

Shouldn't take.

A

A

uh We're just building from Source this shouldn't take long uh one day, I started building um Unreal Engine from source, because I think I naively, like that's I, know it's because my because my distro I couldn't I was using certain Linux distro that I couldn't use any of their executables anyways that took like more than 24 hours for it to build from Source I.

B

Did that multiple times, oh.

A

My gosh and you got to be familiar with it, Marco doing C plus plus stuff. So oh yeah, that's great okay. So this this um came out. What was the artifact that got produced here?

A

If I go to this desktop? Oh, is it just? Oh there? It is it's just there. Okay,.

E

A

Let's make sure let's make a temp directory and let's copy this desktop.

A

Let's copy this into the temp directory, okay, so now I am going to run clean.

A

Hopefully that gets rid of this desktop yes great uh and then I'm going to curl and apply the Mr changes um and I'll run npm install.

B

Okay confirm that CI stands for cleaning install I, checked.

A

Are you, are you serious? No, oh, okay.

B

And that's on the on the node.js documentation. It says this common is similar to 7pm Mr, but it's meant to be used in CI environments to do a claim. Installation.

A

It's a double entender. Is that the right phrase for it? It has two meanings.

E

A

E

A

You want to set up. You want to set up your clean, install Pipelines.

A

All right, so this is the uh this- is I'm going to rename this to uh Orange.

A

And then I'm going to copy um the one that came out of.

E

A

A

All right so now, I have new and a rich I'm going to jump into there. I'm actually pretty sure I have to put these in different um folders when I unzip. It I'm always not certain about this. So.

E

A

Going to actually create a new directory and in a ridge directory and I'm going to copy the new one into the new. Let me move the new one into the new directory, with both the original directory all right exceeding into the new one. Let me rename new from vsix to oops and unzip do not zip boom.

A

Let me go to a ridge uh uh what am I doing: I'm gonna I'm.

E

Gonna be in the terminal.

A

Right now, uh okay, where am I at all right, cdridge I, don't have anything here, I'm going to move this to zip unzip great! Let me remove the or, if I was smart, I would actually move my this down.

A

um Let me move the new one two here: okay, so now I'm ready to go diff you new or Ridge, and new, oh and I- think I also gotta do like recursive Maybe.

A

ah uh How do I do this.

A

Shift directories.

A

Diff Dash r. Oh! No, that but that's not working.

A

Oh, it looks like it automatically.

E

A

I don't know what this is: let's try to do stiff without that.

A

Common subdirectories: what are you saying, I, don't know if it's uh actually doing this asynchronously or not? Oh, maybe I can just use git def get diff we'll do it.

A

Is it really the same I'm not I'm, not trusting it. Let me try adding a test file here.

A

uh Where are we at I lost? My I lost my thing: I always pick it zoom's in my way, yeah. It's not.

E

Doing its thing, what's wrong with you,.

A

Does anyone know how to.

A

Get Biff recursively.

D

When you did that diff minor sorry was capital r, but the documentation said lowercase R. Did you try that.

A

Have a lowercase R here.

A

um And I added this for regular diff, not.

D

A

That's right: oh Mama's, okay, some large files, um let's uh Zooms in the way so now I really wanted to see. Are these changes? um Are these changes just trivial or not so I'm going to call this results.

A

And I can just open it up and go mine. Finally,.

B

um Good luck with that yeah.

D

Compiled JavaScript fundament read.

A

Yeah I guess I, don't know if I can actually do this. uh Well, let's, let's look at it this way. If I look at the file size of oh yeah yeah, let me look at the um well I know we're at time, but I can look at the disk usage of both folders to confirm.

A

Are we kind of the same size or is even the size changing and if the size is changing a lot that would be like what's going.

E

A

But we are in um I've got a little warning going on off my head. Not only that we're at time, but like take it easy Paul. This is two you're too paranoid right now, so yeah uh but yeah I'm, gonna, I'm gonna check out the disk usage and I'm I'm, assuming it's going to probably be the same, and if it's very similar or the same and things pass the smoke test. Then I'll end up merging this one but yeah, but.

B

Checking the size isn't really that good of an indicator because they could change a word to another one.

A

I know you don't have to make.

B

A

D

You're gonna don't make me more.

B

Paranoid, no, it's not to make him even more paranoid. It's just, but.

A

It's true, I know all right, cool I appreciate your all time. What are we gonna say: Terry I.

F

Was gonna, say: I left one for next time, because all of your dependency Mrs, they all have passing Pipelines. Oh.

C

F

Like half or over half of mine, don't wow, so maybe we can look at that next time because right now, I'm just like I'm gonna, let them chill I, don't have time for this right now. So yeah.

A

That's tough yeah.

F

All right, that's for next time. Okay,.

A

I'll catch y'all later bye, bye.