🧭 Introduction
Let’s be real: managing software dependencies manually in a CI/CD pipeline is like trying to herd cats... during a thunderstorm... in traffic. That’s why AWS CodeArtifact exists.
In this blog, I’ll walk you through how I set up CodeArtifact as the artifact repository for my DevOps CI/CD pipeline. It’s part of a larger series I’m working on to automate builds, deployments, and all that good stuff—think of this as Level 3 of my DevOps questline.
If you're new to DevOps or AWS, don’t worry—I’m not here to confuse you with cloud jargon. Let’s decode this together, one secure token at a time.
🛠️ Tools and Services I Used
- AWS EC2 – for compute power
- AWS CodeArtifact – our main character: a managed artifact repo
- IAM (Identity and Access Management) – for managing who gets to do what
- Maven – for building and managing Java project dependencies
🧱 What Is CodeArtifact and Why Should You Care?
CodeArtifact is basically your project’s package pantry. Instead of hunting dependencies all over the internet every time you build your app, CodeArtifact lets you keep everything in a neat, secure, version-controlled repository.
Think of it like this:
Without CodeArtifact: Your builds go out like door-to-door salesmen asking for dependencies.
With CodeArtifact: Your builds walk into a well-stocked internal warehouse and grab what they need.
Cool, right?
🧩 Setting Up the Repository
🧭 Step 1: Create a Domain and Repository
In CodeArtifact, a domain is like a shared space for multiple repositories. I created one to keep all my DevOps artifacts organized.
Then, I set my repository to use Maven Central as its upstream source—this means if CodeArtifact doesn’t have a package locally, it fetches it from Maven Central automatically.
🔐 Step 2: Handle Security Like a Pro
You need a token to interact with CodeArtifact. But here’s the catch—my EC2 instance had zero permissions. Nada.
So I created an IAM policy that:
- Allows fetching an auth token
- Lets Maven read packages
- Talks to AWS STS (Security Token Service)
I then:
- Created a new IAM role with this policy
- Assigned that role to my EC2 instance
Result? Instant access. 💥
Security tip: Always use IAM roles instead of hardcoded credentials. It’s safer, more scalable, and makes your future self thank you.
⚙️ Maven Setup – Enter settings.xml
I edited my Maven settings.xml to include:
- The CodeArtifact repository URL
- An auth token from the role on my EC2
Then I ran mvn compile and held my breath…
Boom. It worked.
Maven pulled down all dependencies from CodeArtifact (or upstream), stored them locally, and built my web app. No warnings, no errors. Just clean, smooth dependency flow.
🔍 Post-Build: The Magic Moment
After compiling, I checked the CodeArtifact repo—and there they were: all the dependencies cached and stored like treasures in a vault.
At that moment, I realized: my CI/CD workflow just got way smarter. My builds will now be faster, safer, and far less brittle.
💡 What I Learned
This project taught me:
- How to properly set up AWS CodeArtifact with Maven
- Why IAM roles > access keys (ALWAYS)
- How to troubleshoot token errors like a DevOps detective
And most importantly: how a good artifact repository is the quiet MVP of every CI/CD pipeline.
🗺️ What’s Next?
This was Part 3 in my DevOps journey. Up next: automating build + deploy stages, integrating testing, and maybe even sprinkling some Lambda magic in there.
🧪 TL;DR
- CodeArtifact = internal package repo = fewer build headaches
- Use IAM roles for security—no hardcoded tokens
- Maven +
settings.xml= happy builds - Debugging permission issues is part of the journey
Stay curious. Automate responsibly. Deploy often. 🚀
Top comments (0)