WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=wP3P89YB9fA

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/wP3P89YB9fA.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.760 --> 00:00:17.200
My name is Taylor Luttrell and I'm joined here by Kilian Carlson.

s3
00:00:17.200 --> 00:00:22.720
Together we make developer content at Sonar, the maker of SonarQube.

s4
00:00:22.720 --> 00:00:34.680
But today, in particular, we are jazzed, dare I say, to get you all up and running with Git Guardian so that you can both find and critically fix issues

s5
00:00:34.680 --> 00:00:39.160
in your AI-generated code before they ever emerge.

s6
00:00:39.160 --> 00:00:51.280
Now, before we dive into the hands-on demo itself, if you would please direct your attention to one of the screens on either side of this room, we've provided for you a QR code

s7
00:00:51.280 --> 00:01:02.360
and also a link there below which, once followed, you can use to set up a free, I should note free, 14-day pro trial for Git Guardian.

s8
00:01:02.360 --> 00:01:10.960
So, this is going to be really important if you want to follow along step-by-step and play-by-play with this workshop, you're going to need Git Guardian.

s9
00:01:10.960 --> 00:01:15.560
So, we'll give you all a minute to get that set up, should you like.

s10
00:01:15.560 --> 00:01:27.440
And just in the meantime, while you do configure that, if I could get a quick show of hands from the audience, who amongst you is already using an AI code reviewer

s11
00:01:27.440 --> 00:01:30.560
as part of your CI process?

s12
00:01:31.240 --> 00:01:35.560
Okay, so that's a fair number of you all and that's what we like to see.

s13
00:01:35.560 --> 00:01:42.320
And whether you are or you're not, we hope that you will be able to derive some utility from today's session.

s14
00:01:42.320 --> 00:01:48.360
We'll give you all just another minute as you sign in to Git Guardian and set up that trial.

s15
00:01:54.520 --> 00:02:05.292
Next I have for you another QR code and I promise this presentation is not exclusively QR codes, but this one is in fact very important as this will take you to

s16
00:02:05.292 --> 00:02:11.652
the dedicated GitHub workshop repo that we have created so that you can get up and running with Guitar.

s17
00:02:11.652 --> 00:02:24.932
This project is going to help exercise some of Guitar's incredible capabilities and Mr. Killian here is going to walk you all through that in a minute, but as you get set up, I do want to note that

s18
00:02:24.932 --> 00:02:28.332
everything we do in this session is going to occur in the browser.

s19
00:02:28.332 --> 00:02:33.132
So, you're not going to need to set up any local tools, install any local environments.

s20
00:02:33.132 --> 00:02:38.972
All you need is a GitHub account and access to Guitar to follow along play by play.

s21
00:02:38.972 --> 00:02:43.772
Uh just a couple of housekeeping notes as y'all are getting signed in and set up.

s22
00:02:43.772 --> 00:02:50.692
Uh in this workshop, we're going to guide you through a few different things, namely installing Guitar as a GitHub app.

s23
00:02:50.692 --> 00:02:52.652
Going to need access to GitHub for that.

s24
00:02:52.652 --> 00:02:58.372
And then critically utilizing Guitar across a few different pull request scenarios.

s25
00:02:58.372 --> 00:03:09.612
We have three prepared for you in this demonstration that are going to demonstrate how verification with Guitar goes beyond simply code review.

s26
00:03:09.612 --> 00:03:13.252
And don't worry, this is very beginner-friendly if you're not especially technical.

s27
00:03:13.252 --> 00:03:22.412
We're going to start slow with Guitar's out-of-the-box verification and then we're slowly going to ramp and build into some of the more advanced features.

s28
00:03:22.412 --> 00:03:29.452
We're actually going to create a project-specific configuration that teaches Guitar your project's conventions.

s29
00:03:29.452 --> 00:03:39.332
And then lastly, we're going to round things out with a CI uh failure diagnosis and you're going to watch some automated fixes occur directly on your PRs.

s30
00:03:39.332 --> 00:03:51.172
So, if you follow along with Guitar and with this repository, then by the end of this workshop, you're going to walk away with Guitar installed, three verified pull requests,

s31
00:03:51.172 --> 00:04:04.814
as well as a practical understanding of a number of things such as, but not limited to, verification instructions, rules for your repositories, as well as CI failure analysis.

s32
00:04:05.614 --> 00:04:08.414
I hope by now you're all set up with guitar.

s33
00:04:08.414 --> 00:04:09.654
You've logged into GitHub.

s34
00:04:09.654 --> 00:04:19.134
Go ahead and refrain from forking the repository right now, as Killian's going to walk you through the steps uh specific for our configuration.

s35
00:04:19.654 --> 00:04:35.614
I want to start instead with a scenario that I'm sure many, if not most of us are intimately and also frustratingly familiar with, which is we all know that AI coding agents are wildly effective

s36
00:04:35.614 --> 00:04:49.134
at writing code, both at speed and also at volume, but while these agents are supercharging our teams to write more code and much more quickly, we ought to pause

s37
00:04:49.134 --> 00:04:57.694
and ask ourselves who or what is actually verifying the code that our agents ship.

s38
00:04:57.694 --> 00:05:10.134
And whether consequently the code that our agents ship is not only secure, of course, and maintainable and reliable, but also whether it is practically and not just functionally or technically

s39
00:05:10.134 --> 00:05:11.814
correct.

s40
00:05:11.814 --> 00:05:25.734
As we know, agents, as they're generating more code and they're doing so faster than anyone can realistically inspect, a couple serious issues have begun to arise.

s41
00:05:25.854 --> 00:05:30.774
The first is an obvious review bottleneck.

s42
00:05:30.774 --> 00:05:39.534
We have teams with a fixed number of members, but which are now facing an increasing number of changes uh via their AI agents.

s43
00:05:39.534 --> 00:05:52.694
They're being inundated with code to review, and as a result, queues are growing, merges are sitting waiting and unattended to, and reviewing is essentially becoming uh a job, a chore, if you will, that nobody

s44
00:05:52.694 --> 00:05:57.734
wants to handle and simply doesn't have the time or the resources to tackle.

s45
00:05:57.734 --> 00:06:04.134
Number two is we're noticing an increase in the number of production incidents.

s46
00:06:04.134 --> 00:06:18.375
As incidents scale with the rate of change given that coding agents do not always respect the project architectures that you spend so much time devising your team or your company or organizations

s47
00:06:18.375 --> 00:06:21.415
coding standards or any of the guidelines that you've established.

s48
00:06:21.415 --> 00:06:22.815
They're unaware of those things.

s49
00:06:22.815 --> 00:06:25.055
They lack the proper context.

s50
00:06:25.055 --> 00:06:40.975
And with these issues threatening to undo the very progress that coding agents promise, the answer has to be faster than um anything that humans can perform and also better than human review

s51
00:06:40.975 --> 00:06:45.495
in order to keep up with the rate of changes that are being introduced by these agents.

s52
00:06:45.495 --> 00:06:54.535
And so, what we have for you is Guitar, which is the code change verification agent.

s53
00:06:54.535 --> 00:07:08.215
And it stands out apart from and above the rest in a number of ways, namely it functions with a high signal to noise ratio and effectively minimizing the false positives,

s54
00:07:08.215 --> 00:07:14.855
the number of false positives in order to improve the fix rate and reduce token expenses as well.

s55
00:07:14.855 --> 00:07:17.255
It diagnoses CI failures.

s56
00:07:17.255 --> 00:07:19.055
This is really unique.

s57
00:07:19.055 --> 00:07:23.815
And it separates real breakages from flaky noise or infrastructure noise.

s58
00:07:23.815 --> 00:07:28.255
And it also, crucially, fixes these issues accordingly.

s59
00:07:28.255 --> 00:07:32.055
And it fixes autonomously also.

s60
00:07:32.055 --> 00:07:37.215
So, that you can move forward as quickly and as freely as possible.

s61
00:07:37.215 --> 00:07:43.255
Effectively, you choose your level of automation and you also choose your level of involvement.

s62
00:07:43.255 --> 00:07:44.935
We're giving you the reins.

s63
00:07:44.935 --> 00:07:55.095
Guitar also iterates until all of your changes pass CI to be absolutely certain that you can ship the code that your agents are generating.

s64
00:07:55.095 --> 00:08:08.377
And lastly, it provides a high degree of transparency into the review process and your CI through a number of dedicated analytics dashboards so that you can continuously improve the speed,

s65
00:08:08.377 --> 00:08:12.417
quality, and effectiveness of your code delivery.

s66
00:08:12.417 --> 00:08:25.617
So, in essence, and and just to recap, Git Tarr is designed for platform and engineering teams uh who need to ship code with confidence at agentic volume and also agentic velocity.

s67
00:08:25.617 --> 00:08:33.297
And it complements SonarQube with an understanding of each code changes context and intent.

s68
00:08:35.377 --> 00:08:43.777
And Git Tarr leverages a variety and a a wide body of context sources to accomplish this.

s69
00:08:43.777 --> 00:08:59.257
Suggesting educated and informed fixes from such things as PR diffs and details and comments and whatnot um from the CI uh CI logs as well, the the very logs that I personally hate to to have to sift through.

s70
00:08:59.257 --> 00:09:03.057
Um from project-specific instructions as well.

s71
00:09:03.057 --> 00:09:08.657
Um configurations that you can write yourself in the repository rules and and much much more.

s72
00:09:08.657 --> 00:09:11.977
And we're going to dive into some of those during the session uh today.

s73
00:09:11.977 --> 00:09:23.457
And I should note that for anybody who is worried about noise, as I mentioned uh Git Tarr is tuned for signal uh because we understand that every false positive is a token spent

s74
00:09:23.457 --> 00:09:28.337
and a fix attempt that risks an unintended change.

s75
00:09:28.337 --> 00:09:39.217
Um and rather than adding more noise and burdensome decisions to an already complicated review process, Git Tarr does do the work of getting the change through and in the process

s76
00:09:39.217 --> 00:09:44.857
verifying and fixing everything so that you don't have to yourself.

s77
00:09:45.057 --> 00:09:57.817
At a high level Git Tarr's review engine is triggered when a PR is opened and it calls upon that wide body of context that we just spoke about to produce findings

s78
00:09:57.817 --> 00:10:12.338
and also fixes posted directly to your pull requests as actionable guidance that you can interact with with comments or if enabled, automatically fixed and merged.

s79
00:10:12.338 --> 00:10:20.218
And to demonstrate just that, I'm going to pass things off to Kilian, who's going to walk you through the hands-on component of this workshop.

s80
00:10:20.218 --> 00:10:25.218
Should you have any questions, if you get blocked, feel free to raise your hand or call on me.

s81
00:10:25.218 --> 00:10:29.218
I'm going to be walking around the room and I'm happy to assist should you all need any help.

s82
00:10:29.218 --> 00:10:30.258
Thank you.

s83
00:10:30.258 --> 00:10:31.058
Cool.

s84
00:10:31.058 --> 00:10:32.258
Thank you very much, Taylor.

s85
00:10:32.258 --> 00:10:34.578
Um hey everybody, I am Kilian.

s86
00:10:34.578 --> 00:10:37.578
I am a developer content engineer at Sonar.

s87
00:10:37.578 --> 00:10:43.458
And um we're going to hop into the hands-on section of this workshop.

s88
00:10:43.458 --> 00:10:52.298
And before we do that, uh the first thing, like Taylor mentioned earlier, is we're going to want to have the Guitar app already installed.

s89
00:10:52.298 --> 00:11:01.378
So, if you haven't done that yet, please go to app.guitar.ai and sign in from there and then start the GitHub install.

s90
00:11:01.378 --> 00:11:05.298
And the second thing is right here, I have the workshop repo.

s91
00:11:05.298 --> 00:11:15.338
It's at github.com/sonarsamples/aie-new-york-workshop-guitar, but you can find it under the repos tab.

s92
00:11:15.338 --> 00:11:24.578
And the first thing that we're what going to want to do is just go ahead and fork the repo.

s93
00:11:24.578 --> 00:11:31.578
And make sure that the owner is the organization that you've installed the Guitar app to.

s94
00:11:31.578 --> 00:11:33.058
And you can name it anything.

s95
00:11:33.058 --> 00:11:34.418
You can keep the name.

s96
00:11:34.418 --> 00:11:38.778
You can name, you know, test run, whatever works for you.

s97
00:11:38.778 --> 00:11:47.098
But the most important thing is that this right here, copy the main branch only is unchecked.

s98
00:11:47.098 --> 00:11:57.418
There are multiple branches for different exercises I'm going to walk through, and if you only copy over the main branch, you're not going to get those different exercises.

s99
00:11:57.418 --> 00:12:02.378
So, we're going to go ahead and click create fork.

s100
00:12:03.738 --> 00:12:10.538
And once that's done, the next thing that we're going to want to do is hop into actions.

s101
00:12:10.538 --> 00:12:15.699
Right, by default, GitHub disables workflows from forks.

s102
00:12:15.699 --> 00:12:23.099
And in order to set up some of the things that we're going to do, like automated merging and approvals, you're going to want to enable that.

s103
00:12:23.099 --> 00:12:33.059
And then the last thing is that if you want to make sure that Guitar is able to read this fork, you can go into the Guitar dashboard.

s104
00:12:33.059 --> 00:12:36.619
Um go to settings.

s105
00:12:36.899 --> 00:12:43.459
Go to configurations and repositories, and you should see your repo pop up there.

s106
00:12:43.459 --> 00:12:48.019
But okay, just to hop into this exercise.

s107
00:12:48.019 --> 00:12:56.183
I have here Box Office, which is a fake sample ticketing API for a small concert venue.

s108
00:12:56.183 --> 00:12:56.259
[snorts]

s109
00:12:56.259 --> 00:13:01.139
And it's it's a pretty simple Python project.

s110
00:13:01.139 --> 00:13:10.179
We have orders.py here, where somebody is able to purchase a ticket or cancel it and get refunded.

s111
00:13:10.179 --> 00:13:21.539
We also um have this uh checkin.py, and what this does it just handles the logic for somebody to hypothetically be able to scan a QR code and get someone into a concert.

s112
00:13:21.539 --> 00:13:31.579
And this is a pretty basic uh example application, but there is a test suite here um that cover all of the existing uh functionality.

s113
00:13:31.579 --> 00:13:37.979
And every time a PR is opened, uh the test will run.

s114
00:13:37.979 --> 00:13:46.379
And so, what we're going to do right now is actually open pull requests for each of the three branches that are in there.

s115
00:13:46.379 --> 00:13:59.179
And the reason for that is because Guitar can take a few minutes to run, and instead of having to wait for each review to happen sequentially, we're going to open them all up and then go through them step-by-step.

s116
00:13:59.179 --> 00:14:08.899
One thing to note is make sure that you set your base repository to um what you are trying to do.

s117
00:14:08.899 --> 00:14:15.299
Uh set your set your base repository to the fork that you have made.

s118
00:14:15.299 --> 00:14:21.661
So, I accidentally hopped back to the base repository, but yep, right here.

s119
00:14:21.661 --> 00:14:24.861
So, I'm going to open new pull request.

s120
00:14:26.581 --> 00:14:30.261
Oops, I kept on checking it.

s121
00:14:31.160 --> 00:14:33.160
[snorts]

s122
00:14:39.021 --> 00:14:50.981
Yep, so you're going to set that to your um run right here, and then click sequentially stage one, stage two, stage three.

s123
00:14:50.981 --> 00:14:54.301
So, yep, create pull request here.

s124
00:15:00.181 --> 00:15:02.941
Going to set up another one.

s125
00:15:06.901 --> 00:15:09.781
Pick stage two.

s126
00:15:11.061 --> 00:15:13.541
Create pull request.

s127
00:15:17.421 --> 00:15:21.061
And then open up the third one.

s128
00:15:26.381 --> 00:15:32.981
Again, make sure that this is opening against your fork and not the upstream repository.

s129
00:15:36.661 --> 00:15:39.141
All right, so all three should be running.

s130
00:15:39.141 --> 00:15:43.141
Guitar should be running its review um while we wait.

s131
00:15:43.141 --> 00:15:47.141
And so, let's hop into the first PR right here.

s132
00:15:47.141 --> 00:15:51.901
Um this is just going to be Guitar's out of the box review.

s133
00:15:51.901 --> 00:15:54.741
We haven't done anything, we haven't configured anything.

s134
00:15:54.741 --> 00:15:58.501
This is just when it looks at a PR, what it suggests.

s135
00:15:58.501 --> 00:16:07.061
And what this change does is we are adding the functionality for someone to order a ticket, and then transfer it to a friend.

s136
00:16:07.061 --> 00:16:13.981
So, if I buy two tickets, and I send one to my friend, we should both be able to go to a concert hypothetically.

s137
00:16:13.981 --> 00:16:21.342
Now, I have included in some pretty basic validation here that just makes sure like, "Hey, the ticket's not found."

s138
00:16:21.342 --> 00:16:27.742
If you don't have a valid email address or it's a voided ticket, it's not going to let you transfer those tickets.

s139
00:16:27.742 --> 00:16:30.782
And uh some tests for that as well.

s140
00:16:30.782 --> 00:16:34.382
And the tests for this uh PR pass.

s141
00:16:34.382 --> 00:16:36.102
The workflow is green.

s142
00:16:36.102 --> 00:16:38.622
The CI is green.

s143
00:16:38.622 --> 00:16:50.182
Um and one thing that I want to point out here as well while we wait for the review to land is that while Guitar is is reading this, it's analyzing

s144
00:16:50.182 --> 00:16:56.062
in a different way than more traditional static analysis tools or other tools might be doing.

s145
00:16:56.062 --> 00:17:11.342
Where static analysis like SonarQube is incredibly important and it catches security issues like SQL injections to where, you know, traveling through 20 different files and functions, it's able to identify

s146
00:17:11.342 --> 00:17:15.622
um you know, SQL injections before they land in your database.

s147
00:17:15.622 --> 00:17:19.822
What it can't do is infer intent, right?

s148
00:17:19.822 --> 00:17:32.662
By looking at your descriptions, your titles, at your existing code base compared to the features that you're adding, it cannot infer that, "Hey, the business logic that is being attempted

s149
00:17:32.662 --> 00:17:37.062
uh to create here um doesn't add up in the way that it should."

s150
00:17:37.062 --> 00:17:40.182
That's why we need both layers on top of each other.

s151
00:17:40.182 --> 00:17:48.302
They cover different capabilities and both of them are complementary towards having a fully verified application.

s152
00:17:48.302 --> 00:17:55.262
We need to be making sure that our code is completely verified as it scales in volume and speed.

s153
00:17:55.262 --> 00:18:00.742
Otherwise, um outages and and breaks are almost guaranteed.

s154
00:18:00.742 --> 00:18:09.742
So, um I'm going to hop back into the main conversations here and we see that Guitar has added a finding.

s155
00:18:09.742 --> 00:18:21.463
So, anytime Guitar finds an issue, it'll add a comment um at the line that it finds an issue and it also posts a code review that has all of its findings,

s156
00:18:21.463 --> 00:18:29.463
as well as descriptions and suggested fixes, and provides a nice summary at a high level.

s157
00:18:29.463 --> 00:18:35.303
If we read this here, it says buyer can refund and void a ticket after giving it away.

s158
00:18:35.303 --> 00:18:39.783
So, when adding this PR, right?

s159
00:18:39.783 --> 00:18:47.623
When you buy a ticket and then send it to someone else, if you go ahead and cancel your original order, it gets canceled for your friend.

s160
00:18:47.623 --> 00:18:47.863
Right?

s161
00:18:47.863 --> 00:18:54.303
This is an edge case that wasn't accounted for, and there wasn't even a test that almost caught this.

s162
00:18:54.303 --> 00:18:59.743
There was a test that said, if you have a voided ticket, it won't let you send it, but not the reverse.

s163
00:18:59.743 --> 00:19:09.903
Um and it also identifies, right here, that the issue is in the original ordering file, orders.py.

s164
00:19:09.903 --> 00:19:19.703
So, the the if you were just a reviewer looking at the diff, you wouldn't necessarily see in the code that you're adding that there's anything wrong.

s165
00:19:19.703 --> 00:19:29.503
You would have to have working knowledge of how cancellations already work in your application in order to understand what's being broken.

s166
00:19:29.503 --> 00:19:36.463
Now, this issue only multiplies as as we do more and more agentic coding.

s167
00:19:36.463 --> 00:19:51.263
The surface area of applications gets more and more complex, um and in order to maintain an understanding of how every last function works is almost impossible at the rate at which we're coding.

s168
00:19:51.263 --> 00:20:04.263
That's why reviewers like Guitar are absolutely necessary because it compares all of your features against existing functionality even when it's not readily apparent in the PR diff.

s169
00:20:04.263 --> 00:20:06.343
And so, awesome.

s170
00:20:06.343 --> 00:20:08.303
Guitar has posted its review.

s171
00:20:08.303 --> 00:20:09.463
Now, what do we do?

s172
00:20:09.463 --> 00:20:10.663
It's very simple.

s173
00:20:10.663 --> 00:20:19.063
You can either click this apply fix right here, or you can just comment Guitar fix, right?

s174
00:20:19.063 --> 00:20:20.543
Comment that.

s175
00:20:20.543 --> 00:20:25.905
What Guitar is then going to do is add a new commit to the PR.

s176
00:20:25.905 --> 00:20:31.585
It will continue to iterate and re-verify the new commit blindly.

s177
00:20:31.585 --> 00:20:43.665
So, if any side effects in the workflows happen to occur, Guitar will keep working, will keep iterating at no extra cost per PR to make sure that it gets fully green

s178
00:20:43.665 --> 00:20:46.025
by the end.

s179
00:20:47.665 --> 00:20:50.945
So, Guitar is working on that extra fix.

s180
00:20:50.945 --> 00:21:02.465
And what it will end up doing is just fixing in that orders.py um file and adding extra validation for this.

s181
00:21:02.465 --> 00:21:14.025
Just takes a couple minutes and it automates this entire process of diagnosing a break, re-pushing, and then fixing and verifying your commits every time.

s182
00:21:14.025 --> 00:21:21.185
I am I am really passionate about the fact that we not cannot be shipping unverified code.

s183
00:21:21.185 --> 00:21:37.705
This is absolutely essential and we need to be verifying every PR with context, with verification, with both deterministic and um a logical understanding of what's being done here.

s184
00:21:37.705 --> 00:21:45.665
So, while this fix lands, it'll just update uh the commit here.

s185
00:21:45.665 --> 00:21:49.105
We'll see it pop up in the files change diff.

s186
00:21:49.105 --> 00:21:58.665
Um it will analyze and make sure that the workflow goes green, and um it should be ready to merge.

s187
00:21:58.665 --> 00:22:06.065
But, I'm going to move on real quick into the second pull request, where we're going to cover context.

s188
00:22:07.345 --> 00:22:17.505
So, every repo or every team has extra rules and uh business logic that doesn't necessarily get represented in the code.

s189
00:22:17.505 --> 00:22:24.745
So, that could be something that lives in your senior engineer's head or in a wiki or in a confluence page or something like that.

s190
00:22:24.745 --> 00:22:30.346
And these business rules don't necessarily have anything to do with code correctness.

s191
00:22:30.346 --> 00:22:38.586
So, for this PR right here, we are adding in a $3.50 service fee for every ticket that's that's purchased.

s192
00:22:38.586 --> 00:22:45.186
So, if you buy a $50 ticket to a concert, at the end you're going to be paying $53.50.

s193
00:22:45.186 --> 00:22:56.106
But, for this hypothetical company right here, they have a rule that says every price we show a customer is the all-in price.

s194
00:22:56.106 --> 00:23:03.266
I don't know about you, but it is the biggest pet peeve in the world for me when I go and buy a ticket for something and it's like $30

s195
00:23:03.266 --> 00:23:07.586
and then with fees and everything like that, it's like $70 by the end of it.

s196
00:23:07.586 --> 00:23:11.466
Um this hypothetical company cares about user experience.

s197
00:23:11.466 --> 00:23:12.866
They care about you.

s198
00:23:12.866 --> 00:23:18.226
So, they have a business rule that says every price we show is the all-in price.

s199
00:23:18.226 --> 00:23:19.906
But, how do we enforce it?

s200
00:23:19.906 --> 00:23:24.866
How do we enforce that this is going to get reviewed by a code review agent.

s201
00:23:24.866 --> 00:23:26.426
Well, there's a couple different ways.

s202
00:23:26.426 --> 00:23:34.706
One is this uh review directory.gitar/reviewdirectory and another one is this .gitar/rulesdirectory.

s203
00:23:35.186 --> 00:23:46.506
So, what a review directory does is you can add all the context you want, as many MD files, as much of your business logic as you want to add and Gitar

s204
00:23:46.506 --> 00:23:51.106
will steer its own reviews according to this.

s205
00:23:51.626 --> 00:23:53.226
And this is super powerful, by the way.

s206
00:23:53.226 --> 00:23:58.106
Like, I encourage you on your own, just throw as much context as you want at it.

s207
00:23:58.106 --> 00:24:04.066
Uh Gitar is incredibly efficient and powerful at ingesting this and applying it.

s208
00:24:04.066 --> 00:24:08.746
Uh for the rule section right here, rules are awesome.

s209
00:24:08.746 --> 00:24:10.426
I set these up all the time.

s210
00:24:10.426 --> 00:24:18.066
Rules are if a certain uh criteria are met by a PR, then a rule will fire and take an action.

s211
00:24:18.066 --> 00:24:30.987
So, for this one, is every time an some of the pricing files are edited or updated, it will check and present to a reviewer a list of hey, these are all the customer facing fields

s212
00:24:30.987 --> 00:24:35.707
that are edited and it'll let you know these are all in or otherwise.

s213
00:24:35.707 --> 00:24:37.827
But you can do a ton with rules.

s214
00:24:37.827 --> 00:24:46.148
Um one that you can do is if let's say you and another engineer are talking about uh a new capability or feature in a Slack thread.

s215
00:24:46.148 --> 00:24:59.627
You can set a rule that says, "Hey, every time I paste a Slack link in my PR description, go into Slack, look at the conversation, and check my code against the discussion that we were having."

s216
00:24:59.627 --> 00:25:02.788
And it'll just fire every time that you do that.

s217
00:25:02.788 --> 00:25:03.947
It's super cool.

s218
00:25:03.947 --> 00:25:06.427
I love this capability.

s219
00:25:06.427 --> 00:25:11.028
Um and if we scroll down, oops, a little sneak peek of what Gittar found there.

s220
00:25:11.028 --> 00:25:18.307
But we can see that um there's this, you know, service fee that gets added and some tests.

s221
00:25:18.307 --> 00:25:25.268
If I hop back into the main conversation, we can see that Gittar posted his code review.

s222
00:25:25.268 --> 00:25:27.107
It posted the rule, right?

s223
00:25:27.107 --> 00:25:34.427
It sees all of these pricing fields and it lets you know, "Oh, this is is or is not an all-in price."

s224
00:25:34.427 --> 00:25:36.028
It finds the bug.

s225
00:25:36.028 --> 00:25:42.148
Now again, guys, this is not an engineering bug per se, right?

s226
00:25:42.148 --> 00:25:54.547
If you're just the world's best programmer in a vacuum, it's it's not like this is incorrect, but according to your business and your use case, this may or may not be what you want to do.

s227
00:25:54.547 --> 00:25:57.028
So Gittar is able to check against this.

s228
00:25:57.028 --> 00:25:59.307
It is so powerful.

s229
00:25:59.307 --> 00:26:02.347
We're not going to go ahead and merge this one in.

s230
00:26:02.347 --> 00:26:08.067
Um we're just going to leave it before hopping into the third exercise.

s231
00:26:09.268 --> 00:26:20.987
Oh, and just um the Gittar fix uh and then I'm going through and it's been fully verified from the previous exercise that we did.

s232
00:26:20.987 --> 00:26:30.107
Um Gittar uh approved it, fixed it, and we can see that um Let me look at the diff.

s233
00:26:30.107 --> 00:26:36.949
Then I went ahead and fixed this orders.py and added in this extra check.

s234
00:26:36.949 --> 00:26:39.149
But moving on to the third exercise.

s235
00:26:39.149 --> 00:26:53.349
And what we're going to do here is we are going to enable full automation and merging complete pipeline verification from the moment you open your PR to the moment that it gets merged in.

s236
00:26:53.349 --> 00:26:55.869
And there's going to be a little bit of settings that we have to adjust here.

s237
00:26:55.869 --> 00:26:58.909
So if you want to follow along, I highly encourage you to.

s238
00:26:58.909 --> 00:27:05.589
If you just want to watch and set this up later, the read me for this repo has all of the instructions available for you.

s239
00:27:05.589 --> 00:27:13.789
Um so the first thing that we're going to want to do is hop into rules, scroll down, and click allow auto merge.

s240
00:27:13.789 --> 00:27:18.709
That sets up the GitHub setting that allows for GitHub's auto merging.

s241
00:27:18.709 --> 00:27:21.869
Next thing is to go to rule sets.

s242
00:27:21.869 --> 00:27:26.949
Hit new rule set, new branch rule set.

s243
00:27:27.189 --> 00:27:35.909
And for rule set name, you can just say, you know, workshop rule or whatever you want it to be.

s244
00:27:35.909 --> 00:27:38.069
Make sure it's active.

s245
00:27:38.069 --> 00:27:42.189
And make sure that you target default branch.

s246
00:27:42.189 --> 00:27:48.949
And the rule that we want to set here, the check we want to set is require status checks to pass.

s247
00:27:48.949 --> 00:28:03.869
And what that will do is if you type in test here, is that we are going to require our CI to go green, our test to pass before we say, "Hey, this is good to go ahead and auto merge."

s248
00:28:04.029 --> 00:28:14.389
Again, if, you know, you missed any of those steps, this is in the read me with all of those different requirements listed there for you.

s249
00:28:14.389 --> 00:28:16.029
So go ahead and create that.

s250
00:28:16.029 --> 00:28:26.829
And if your company has secure off set up like mine does, it may enforce a code, which I have right here.

s251
00:28:29.589 --> 00:28:30.509
Awesome.

s252
00:28:30.509 --> 00:28:30.869
Cool.

s253
00:28:30.869 --> 00:28:34.470
So we've created a new rule set.

s254
00:28:37.950 --> 00:28:41.990
So, you may see already for this PR, it's just been blocked.

s255
00:28:41.990 --> 00:28:43.430
A test has failed.

s256
00:28:43.430 --> 00:28:49.070
But, what this is doing is it is essentially refactoring the way that tickets are scanned.

s257
00:28:49.070 --> 00:28:59.870
Um what it's saying is that, "Hey, we're going to update tickets now at the point to the ticket page URL and refactoring a little bit of the logic that already existed

s258
00:28:59.870 --> 00:29:01.830
within the application."

s259
00:29:01.830 --> 00:29:05.590
Um but the the the test failed.

s260
00:29:05.590 --> 00:29:11.910
And if you go into that and you look at what failed, it says, "Test ticket cannot be scanned twice."

s261
00:29:11.910 --> 00:29:16.030
So, it caught a check that was missed in the refactor.

s262
00:29:16.030 --> 00:29:21.270
Um if I scan my ticket, I should be one and done.

s263
00:29:21.270 --> 00:29:27.190
I don't want to continue scanning over and over and let all my friends use my same ticket behind me.

s264
00:29:27.190 --> 00:29:31.790
It's pretty basic, but it's easy to miss logically.

s265
00:29:32.710 --> 00:29:38.310
In Guitar's uh review, it is able to inspect CI.

s266
00:29:38.310 --> 00:29:39.390
It says CI failed.

s267
00:29:39.390 --> 00:29:41.990
It says, "One test fails at the gate check-in.

s268
00:29:41.990 --> 00:29:45.510
Scanning an already used ticket a second time returns 200."

s269
00:29:45.510 --> 00:29:53.550
So, if you have any failures in your pipeline, Guitar is able to inspect the logs and fix.

s270
00:29:53.550 --> 00:30:08.390
One of the I guess biggest annoyances in my engineering career is like the test log inspection loop, where you have to go in and see what failed and then try and diagnose and then, you know, fix it locally and then push it

s271
00:30:08.390 --> 00:30:09.870
and then wait for the pipeline to rerun.

s272
00:30:09.870 --> 00:30:12.310
And some of these pipelines can get really long.

s273
00:30:12.310 --> 00:30:18.790
And then you're just waiting and then it fails again and it's just this time-consuming, money-burning process.

s274
00:30:18.790 --> 00:30:23.550
And you may even need to like keep pinging another engineer about reviewing.

s275
00:30:23.550 --> 00:30:26.630
And I'm getting a headache just thinking about it.

s276
00:30:26.630 --> 00:30:29.390
Guitar just solves all of that for you.

s277
00:30:29.390 --> 00:30:33.110
It is able to automate that process and keep going.

s278
00:30:33.110 --> 00:30:36.350
So, it's very simple.

s279
00:30:36.350 --> 00:30:51.632
All you have to do is type guitar, sorry I'm doing this with one hand, is guitar auto apply on and then guitar auto merge on.

s280
00:30:51.632 --> 00:31:01.231
And what auto apply is going to do is just allow guitar to keep pushing fixes without needing you to to click yes on it every time.

s281
00:31:01.231 --> 00:31:10.992
And then what auto merge is going to do is whenever it doesn't detect any more issues and whenever your pipeline finally passes fully, it's just going to go ahead and merge that in for you.

s282
00:31:10.992 --> 00:31:14.552
Um cool.

s283
00:31:14.552 --> 00:31:15.941
I'll add that.

s284
00:31:15.941 --> 00:31:17.941
[snorts]

s285
00:31:18.672 --> 00:31:21.432
Guitar auto apply on, guitar auto merge on.

s286
00:31:21.432 --> 00:31:24.512
If I refresh it, guitar Oh, it already did it.

s287
00:31:24.512 --> 00:31:25.872
Hit it with a nice thumbs up.

s288
00:31:25.872 --> 00:31:27.112
Thanks, guitar.

s289
00:31:27.112 --> 00:31:36.552
Um And so, guitar will iterate, push a fix, validate it, verify it, and then eventually merge it in.

s290
00:31:36.552 --> 00:31:39.712
And this will happen within a couple minutes.

s291
00:31:39.712 --> 00:31:43.952
This is beyond powerful, right?

s292
00:31:43.952 --> 00:31:47.952
To be to be able to set up your application.

s293
00:31:47.952 --> 00:31:55.672
And by the way, adding the comment like we did is just for the sake of this workshop because I didn't want to auto merge in the other PRs.

s294
00:31:55.672 --> 00:32:03.872
You are able to go into the guitar dashboard and turn on auto approve and auto merge for any of your repos that you want.

s295
00:32:03.872 --> 00:32:05.112
You can be selective.

s296
00:32:05.112 --> 00:32:10.352
You can choose the level of automation and approval that you set up for each repository.

s297
00:32:10.352 --> 00:32:24.552
If you have an incredibly agentic workflow with tons of guard rails and tests and a sophisticated pipeline, um and then you add guitar on top of that, you're just able to let these rock and roll right off the bat.

s298
00:32:24.552 --> 00:32:27.352
So, I'll refresh this.

s299
00:32:28.432 --> 00:32:39.433
Guitar still working, um but it will continue to go and push until everything is fully merged.

s300
00:32:41.753 --> 00:32:44.033
The repo as well.

s301
00:32:44.033 --> 00:32:48.193
Uh I encourage you to continue working on it on your own at home.

s302
00:32:48.193 --> 00:32:51.572
There are some extra things at the end um that that

s303
00:32:51.572 --> 00:32:51.673
[snorts]

s304
00:32:51.673 --> 00:32:54.953
are more advanced capabilities for you to check out.

s305
00:32:54.953 --> 00:33:04.993
Uh Taylor's going to talk about a few of them, but you have a 14-day pro trial that I encourage you to use on this repo, that I encourage you to use on your own repositories.

s306
00:33:04.993 --> 00:33:08.553
Um I think you're going to get a lot out of it.

s307
00:33:08.553 --> 00:33:23.033
Um so instead of uh holding y'all hostage to watch Guitar add its uh auto merge in as it's iterating and applying those fixes, I'm going to pass it over to Taylor to talk about a few more

s308
00:33:23.033 --> 00:33:24.153
features.

s309
00:33:24.153 --> 00:33:26.953
Well, thank you Killian for the insightful demo.

s310
00:33:26.953 --> 00:33:31.553
I hope that we were able to help y'all get a rocking and rolling with Guitar.

s311
00:33:31.553 --> 00:33:44.113
Just want to pop back up to discuss a couple more advanced features that Killian has just mentioned, uh which he touched on, but whose walk-through would go beyond the scope of this short and simple workshop.

s312
00:33:44.113 --> 00:33:52.673
So, first note that at the bottom of the read me in the repo is a take it further section, as he just mentioned.

s313
00:33:52.673 --> 00:33:55.633
I would encourage y'all to follow that after this workshop.

s314
00:33:55.633 --> 00:33:58.033
Follow it at your own pace, take it home.

s315
00:33:58.033 --> 00:34:09.993
Um but to quickly highlight, Guitar does enable some additional features including but not limited to number one, functional validation.

s316
00:34:09.993 --> 00:34:16.473
As Killian mentioned, it checks each PR against the ticket in the case of Jira that it implements.

s317
00:34:16.473 --> 00:34:23.393
And this is really powerful because it ensures that the change is correct and complete and not just clean.

s318
00:34:23.393 --> 00:34:24.513
All right?

s319
00:34:24.513 --> 00:34:26.633
So, it works with Jira currently, linear.

s320
00:34:26.633 --> 00:34:35.473
It works with Slack as well, which you can can connect through the Guitar dashboard at settings and integrations.

s321
00:34:35.473 --> 00:34:45.234
For example, you can reference a Slack message or a Jira ticket to better inform and structure your reviews with Guitar.

s322
00:34:45.234 --> 00:34:57.434
Guitar also takes advantage of a feature that we're calling knowledge, which learns conventions and also references false positives from the feedback that it receives and the feedback that you provide

s323
00:34:57.434 --> 00:34:57.714
to it.

s324
00:34:57.714 --> 00:35:01.954
And it's weighted by reviewer seniority, actually, which is pretty neat.

s325
00:35:01.954 --> 00:35:11.114
Um and this shows essentially the rules behind every review, where they come from, and why they're coming into play.

s326
00:35:11.114 --> 00:35:13.194
There's two that I would like to show you all today.

s327
00:35:13.194 --> 00:35:18.314
The first is cross repo, and the other is cross PR analysis.

s328
00:35:18.314 --> 00:35:30.354
Cross repo analysis finds PRs that may very well merge cleanly independently, but um but break code in another repo.

s329
00:35:30.354 --> 00:35:30.594
Right?

s330
00:35:30.594 --> 00:35:34.434
And there's actually no limit on how many repos it analyzes.

s331
00:35:34.434 --> 00:35:35.874
Just food for thought.

s332
00:35:35.874 --> 00:35:43.754
Um and then there's cross PR analysis as well, which checks in-flight PRs against each other.

s333
00:35:43.754 --> 00:35:55.754
As you probably know, or may very well have experienced, I certainly have, two PRs can each pass alone and yet still break production together, and that's just a risk

s334
00:35:55.754 --> 00:36:00.514
that grows with every agent you add into the stack.

s335
00:36:00.514 --> 00:36:03.074
So, Killian's walking you through the dashboard.

s336
00:36:03.074 --> 00:36:06.594
Um just to quickly touch on each of those features.

s337
00:36:06.594 --> 00:36:10.794
Um if you would, perhaps we could click into a single one of these findings.

s338
00:36:10.794 --> 00:36:16.834
Note that it points you to the fix, shows you where this is occurring, and importantly, why it actually matters, right?

s339
00:36:16.834 --> 00:36:23.834
Why you want to defer to a uh to Guitar to go about uh fixing it.

s340
00:36:24.474 --> 00:36:29.074
And that is Guitar in a nutshell.

s341
00:36:29.074 --> 00:36:32.634
We hope that y'all have found some utility from this.

s342
00:36:32.634 --> 00:36:39.034
Um again, feel free to take this home should you like to better familiarize yourself with the tool.

s343
00:36:39.034 --> 00:36:45.796
Play around with all of the context that you can throw at it to get better and more informed reviews.

s344
00:36:45.796 --> 00:36:49.756
Um there are a couple that come with the um enterprise feature.

s345
00:36:49.756 --> 00:36:52.796
All of this is going to to ship with with Pro.

s346
00:36:52.796 --> 00:36:54.916
And so we'll open the floor now to any questions.

s347
00:36:54.916 --> 00:36:58.796
Should y'all have any questions for us, we'd be happy to answer those.

s348
00:36:58.796 --> 00:37:01.076
Thank you very much.

s349
00:37:01.076 --> 00:37:03.436
Yes, so Git Tower has MCP connectivity.

s350
00:37:03.436 --> 00:37:08.036
It's able to ingest um context like that in a variety of ways.

s351
00:37:08.036 --> 00:37:08.756
Um

s352
00:37:08.756 --> 00:37:10.436
Configure your own integrations.

s353
00:37:10.436 --> 00:37:11.036
Yeah.

s354
00:37:11.036 --> 00:37:14.396
That that sounds a little bit different from the knowledge capability that we have.

s355
00:37:14.396 --> 00:37:22.196
That sounds more like the context capabilities where it'll review, you know, code against, you know, like architecture guidelines and things like that.

s356
00:37:22.196 --> 00:37:27.516
The knowledge tab that we have is um steering Git Tower specific reviews.

s357
00:37:27.516 --> 00:37:39.756
So if Git Tower posts a review and suggests a fix in a certain way, you can say, "Hey, we actually tend to fix stuff in, you know, this type of way or or XYZ manner."

s358
00:37:39.756 --> 00:37:44.156
And Git Tower can save that for its own fixes in the future.

s359
00:37:44.156 --> 00:37:44.956
That's a great question.

s360
00:37:44.956 --> 00:37:50.396
I'd have to follow up on you about how exactly knowledge ingestion works.

s361
00:37:50.396 --> 00:37:58.756
Um but I I I believe I actually I actually know for a fact that there are ways to get that connected, whether that's in the knowledge feature itself.

s362
00:37:58.756 --> 00:38:01.916
I would have to follow up with you about that.