Enterprise DevOps & Cloud Infrastructure

Adding a VCS Repo Identifier

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Adding a VCS Repo Identifier" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik validates the changes using Terraform. The repo is then planned and applied. Since Terraform Cloud will be automating the workflow, the execution mode is changed to "remote".


Transcript from the "Adding a VCS Repo Identifier" Lesson

>> So one more time, we're gonna take a super quick look at what we got it, right? So we've added, if we go back, we first added a new data file, right? Make sure you got that. And then we also added to our main, the VCS repo configuration, right?

Now, again, I apologize. I don't have a bunch of resolution at the moment, so you can't see everything here, so I'll keep this open for a second longer.
>> Where in the code did we define that each.value.vcs repo?
>> Yeah, we're not there yet. [LAUGH] Yeah, give me a second, yeah, yeah, yeah.

>> Tricking me here too.
>> It's okay, it's okay. Yeah, I'm just trying to make sure everything is updated on this one. So cool, we've got data, right, we've got main. And then because it was flowed from, [LAUGH] never mind, I'm just kidding. But yeah, we're missing one other thing, right?

We're missing one other thing, which is, were missing our VCS repo identifier. What that means is that, yes, we've told our workspace which ID the GitHub apps installation is, but we also just told it that, hey, we're expecting a new value from our configuration, right? Because the repo name might not match the same name as the workspace, which in this case, it doesn't.

So after we've added our data and we've added the VCS, we go back to locals. Where do you think I go?
>> Workspace.
>> Exactly, and what do you think I add? Y'all come on [LAUGH].
>> Got that VCS.
>> I gotta turn off copilot, man. [LAUGH] But yeah, this is basically what we want, right?

Now, this isn't exactly right because it's actually terraform-tfe, right? But the VCS repo identifier will include the name or owner of the repository, as well as the repository itself, right? So this is the last little bit that we need. So again, if I go all the way to the beginning, data, right?

VCS repo, Right? Variables, Right? And then locals, Right, cool, okay. So now that we've got all that, what's the first thing we do after we make changes?
>> Validate.
>> Validate, yes. So we're gonna validate. We made a whole bunch of changes, let's validate. Because as some of our class members have learned, Terraform will do as far as it can before it fails.

So validation is always super helpful here. Yeah, or at least it'll help, right? It might not always save you, but it can help. So after we do that, then we're gonna do a plan, right, TerraForm plan. And I'm gonna be honest, get comfortable to going back to commands in shell.

[LAUGH] You're gonna do it a lot, up, up, up, down, down, down, and my personal favorite, Ctrl+R. And then you can actually just type in. So I'll do plan, and you'll notice that sometimes it doesn't go to the one I want. So I just use space, then it goes to the one I want.

So again, you can do up, up, go the old up fashion, the old down fashion, or you can do what's called back search or back search in shell. And then you can actually just do plan space, and then that should give you your command. So we hit Enter.

Okay, so let's take a look here. We've got GitHub app installation ID, identifier, ingress submodules. Cool, all that got added. But there's something else here that we might not necessarily have that we want. You won't know what it is, but it has to do with the execution mode when we think about it from before.

Right now it's set to local, but if we connect as the VCS and it's set to local, is it gonna run our code?
>> No, [INAUDIBLE] not.
>> It's not, yeah, it's not, yeah, it's not. [LAUGH] It's just gonna see the changes, right? So when I told you guys in the beginning, set local to default, that's because it makes it easy for you to bootstrap these repos and these things like that.

But once you get an automation, that value doesn't matter. We can tell it to do whatever we want. So there is actually one more variable we wanna update here, and it's the execution mode. We wanna set it to remote, because now we're gonna tell Terraform cloud to actually run in Terraform cloud, right?

So now if I do a plan, We should see, wait, what? What's my problem?
>> It's hard-coded.
>> It's hard-coded, yep. I messed up, right? Each., there you go. Thank you copilot. So again, that's why it's really important to think about where you're adding stuff, and make sure that you're doing it in the right places.

Now we see our execution mode set to remote, right? Fantastic, okay, yes.
>> Is this a good pattern to define static values in locals rather than using variables with TF VARs and compute required structure?
>> So I think it's good if you later on want to override values, right?

A lot of the stuff that I'm using in variables, again, I'm using it because my organization name might change, my installation ID might change, my GitHub organization name might change, right? So those are when I think it's valuable to create a TF variables file, put it in that.

But right now, we're only doing this for this one repo. Going forward, we're actually gonna use Terraform code to configure our workspaces, right? And again, we'll get into that in a second, but this is only really for the initial bootstrapping. We solve configuration via variables in the automation too.

Let's do this one more time. Again, I'm gonna plan really fast, make sure my changes are accurate, right? And then I'm gonna do an apply.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now