Video summary
This video introduces a practical workflow for resolving code review issues in the Tanuki IT platform by leveraging GitLab's integration with OpenAI Codex. The presenter identifies a specific bug where the API endpoint for submitting metrics fails to properly validate empty sensor values, incorrectly returning an HTTP 201 status instead of the expected HTTP 400 error. To address this, the speaker demonstrates how Codex can be utilized as an external agent within the GitLab Dev Edition platform to automatically generate fixes. By invoking the agent directly on a merge request, Codex analyzes the context, implements the necessary validation logic, and adds corresponding test cases to ensure that invalid data is rejected correctly, thereby preventing potential security vulnerabilities and incorrect user interface behavior.
Once the initial fix is generated, the process moves into the standard code review phase where GitLab Duo provides automated feedback based on Rust style guides and API change requirements. The system highlights two main areas for improvement: the need for documentation comments on public items and the requirement for handler tests covering both success and failure paths. Instead of manually addressing these points, the presenter shows how to assign the `@ai-codex-agent` directly within a merge request comment to request further assistance. This triggers an interactive session where Codex reviews the feedback, applies the missing documentation, adds the specific test case for blank metric validation, and reruns all local checks and CI/CD pipelines to ensure everything passes before human approval is required.
The demonstration concludes by highlighting the efficiency of using external AI agents to streamline development workflows without the need for complex configuration or additional credit management, as Codex uses GitLab-managed credentials automatically. The presenter emphasizes that this approach allows developers to combine Codex's coding capabilities with GitLab Duo's code review features and other custom agents to handle bug fixes and feature implementations more effectively. Ultimately, the video illustrates a robust method where AI agents not only write code but also participate in the review loop, ensuring high code quality, comprehensive test coverage, and adherence to project standards before a human developer performs the final verification and merges the changes.
Read the full video transcript
Hello everyone. My name is Michael. I'm
a principal developer advocate here at
GitLab and in today's session we want to
dive into Codex and GitLab.
Specifically, Codex is an installation
in the GitLab 2 H platform. Um in order
to practice that, we want to look at an
existing problem in the Tanuki IT
platform. In the previous videos, we
discussed um there is a new Rust metric
store um as a back end
and it already had some bug reports um
one of which is that the API endpoint
where we can send in metrics from a
client um doesn't have that much great
error handling or error validation. So,
for example, when you pass in uh a
sensor and the metric um and the the
values are empty, um this is not
explicitly rejected um and the
expectation would be I get an HTTP 400
error um and right now it's just not
that.
So, we need to improve that. Um this
issue issue exists and I already started
working on that with Codex yesterday.
Um so, we do have a merge request um
open over here, but before we dive into
the fix, let's quickly uh look into the
actual problem.
The sensor um value is given, but the
metric is empty or it's blank spaces.
Um this should actually result in an
HTTP 400. When we send it, we can see
it's accepted and it's HTTP 201. So,
this is the faulty behavior.
Um and
we want to fix that.
What I did was um
I used uh Codex already. Let's curl up a
little bit. Um and it implemented uh the
fixes and verified everything working
um and created a merge request for us,
which is right over here.
It's also linked from the issue, so
Codex knows about the context, um,
previous video about uh, the GitLab MCP
server, and, um,
created this fix for us. We have
specific changes here, um,
which, um,
ingests the payload, improve the error
handling, and also add tests.
So, um, this is a good thing. Now, we
want to test that, uh, locally, so let's
copy the branch name, go back into our
terminal,
not this one, but this one, uh, right
over here. So, I've prepared that
already. Let's check out, um, this
specific branch, and then rerun the
application,
um, in order to verify that the error
handling has improved. It compiles the
code,
runs it again,
and let's go with the fix. And we can
see the error message has changed. Now,
we get, uh, a direct error message,
message, HTTP error code 400, and I, or
as a client, I can handle,
uh, the feedback, retry, change it, fix
it, um, and also the platform doesn't
process invalid data, uh, which could
lead into not only, um,
uh, wrong user interface behavior, but
could also open security holes and
whatnot.
Okay, the fix is working. Um, let's look
go back into the merge request itself,
um, and see if anything is to do from a
review perspective. So, the pipelines
are green. Um,
build is okay, the tests have run,
security scanning is happy. Um, the next
step would be, um,
code review with approval,
and we can also see GitLab Duo, uh, code
review already ran, um,
for this merge request, and it found
something. So, it uses specific Rust
style guide review instructions,
and comes to the conclusion it needs
there are changes needed. So, the first
one is that the style guide says all
public items must have documentation
comments, and this one doesn't have any.
It has a suggestion, so we can actually
like apply that now if you want to.
Um and the second comment comment is
about
um
any API changes, and this is an API
change uh require handler tests for
success and failure paths. And this one
is missing a test case for the blank
metric validation, which we just did on
the terminal. So, we actually need to
have a test case for that.
Um and
yeah, that's that's good feedback.
Um to quickly show you the merge request
review instructions over here, um this
is actually documented or like defined
here that handler tests need to be
created and and also like Rust items.
And yeah,
number four is about public items must
have documentation comments. Um this
ensures that the style guide and the
code quality uh remains intact.
Now,
uh what what can we do with that
feedback? This one is something we can
apply. This one is something we need to
think about ourselves. So, we could
either take it down to the terminal now
and ask Codex to help address the merge
request feedback um using the GitLab MC
P server, or another way is uh we want
to use Codex as an external agent on the
GitLab Dev Edition platform itself,
um which allows us to directly um
run it in a background um session and
address the review feedback. Um in order
to do that, uh we need to quickly learn
about external agents uh in in the do
agent platform where you can see here in
the docs there's a quick start guide and
scrolling down here to the Codex agent.
Uh it uses GitLab managed credentials
and doesn't require additional
configuration, which is great. So, we
don't need to worry about um the the
credits in the background um or any
specific configuration, but rather much
can start using it. In or in order to do
that, you need to enable the agent uh
from the AI catalog into your project,
uh
which I did already, but we can quickly
go here in AI into agents,
uh where you can
see the agents that I have enabled, but
there is also access to the AI catalog
where you can see the Codex agent here
and you can enable it into your project.
I did that already, so um it's
it's here, it's available. And the most
important part um here is to know that
the Codex agent uses a service account,
which we can use then to reference it.
So, if I want to @mention it or assign
it, um I need to know that it's
@ai-codex-agent
and so on.
Um so, let's remember that um because
now we want to invoke the agent on the
merge request feedback.
And let's [snorts] go back into the
merge request.
Go here and start typing @ai-
codex
and auto complete is helpful.
Um please help address
the review feed back
and push fix.
Or something like that.
Uh let's add that comment.
And we can see uh the Codex agent
gets triggered by this event or this
admission event and starts a new
session. So, we can either click here
um to automatically see the session
inside, which opens a new tab, um or if
you want to stay in the same context on
the right-hand side, you have the
sessions and we can see that
um
the codex agent triggered that session
again with all the details. So, right
now it's running and this takes some
minutes.
Codex um directly added a fix into uh
the merge request and added a comment
that it added uh the blank metric metric
validation test to ensure handler
coverage matches the validation logic.
All rust checks and tests have been
rerun locally for the branch and by
locally it means inside the agent
session.
Um so, let's quickly inspect
the diff here.
And we can see it added uh a new test
case.
And
the new test case should have
automatically triggered
CI/CD pipelines.
Let's go here, press refresh. Yes.
Now it's building everything again.
The tests have run successfully. Let's
quickly chime into that.
Can see
um
metrics for unknown sensors empty,
sensor returns.
Um
where is it?
Now I need to check the diff again. Um
This one here.
It checks blank metric.
Uh let's go back into the merge request
pipelines.
We're here to test.
And
Where is it? Ah, there it is.
Okay, so the test has successfully run.
Um it used I think it uses a function
callback to automatically register that
register that in the test framework in
in Rust and Cargo, which is
which is great.
And it has also running okay. So
everything is green.
Um the next step is that we can pull the
changes locally to
to continue or to resume the Codex
session and continue work on the merge
request itself.
Um
then uh specifically
verify security scanning has nothing uh
detected.
Uh do an do an an additional approval
from a human in the loop. Um and then
verify that uh the closing for the issue
is actually valid. So an additional use
case for uh Codex could be to add
mention it and say, "Please help me
verify everything against uh the linked
issue 33." Um and then you get a summary
of like what is missing um and so on. So
there are multiple ways how you can
interact with the different agents,
combine Codex as an external agent uh on
the GitLab 2.0 platform together with
dual code review, with specific other
custom agents and flows. Um or um also
work locally uh with adding the GitLab
MCP server into Codex on the CLI. So
there are there are different ways uh to
to approach that and get um efficient in
developing and and implementing features
and of course bug fixes.
Um that being said, um
I think that's it for today. Um I hope
you learned something new about external
agents, Codex, and GitLab.
Um and see you see you next time.
Bye-bye.