Kat CosgroveThis article is part of a series written by JFrog's Developer Advocates. The index can be found here:
AWS has released CodeArtifact, an artifact repository manager, and as an employee of JFrog Iâve obviously got some opinions. My boss said I didnât have to censor snark for this, so before I get to the point, I just want to say this:
I know naming things is hard. There are a million jokes about the difficulties of naming things in computing. AWS already has CodeCommit, CodeBuild, CodeDeploy, CodePipeline, and CodeStar, so maybe they felt backed into a corner because a convention had been established. But, yâall⊠there is already a completely unrelated product called AWS Artifact. Obviously this doesnât impact the quality or usability of the tool and itâs just another example of Amazonâs tendency to forget about the existence of its own tools (understandable, there are SO MANY of them), but itâs confusing and made me chuckle so I had to bring it up.
Anyway, onwards to the point.
Do you like vendor lock-in? So does Amazon. As far as I can tell, CodeArtifact didnât ship with any integrations for the CI/CD tools youâre probably already using and thereâs no word on whether or not integrations will eventually be added. If you want to use CodeArtifact, but youâre already committed to Jenkins and moving everything over would be a bear, youâre in an awkward spot. Yes, thereâs a CLI. You can still kludge something together. Thatâs extra work for something that should be easy, though. Your alternative is to migrate everything over to their ecosystem so you can use AWS CodePipeline, the literal only thing it integrates directly with. Either way, itâs inconvenient at best and a huge pain in the ass at worst. Maybe itâs fine if youâre starting a new project from scratch and are okay with living in Jeffâs house forever, but itâs kind of⊠short-sighted.
Yes, JFrog has its own CI/CD tool. Itâs called Pipelines, and its integration with Artifactory is really, really smooth. Weâve got a CLI and a REST API, too. However, we also have direct integrations for the tools you might already be using -- Jenkins, TeamCity, Bamboo, Azure DevOps, GitHub Actions, and BitBucket Pipelines -- because we want you to be able to use Artifactory and everything it offers regardless of whatever else is going on in your ecosystem. Like, itâd be cool if you used Pipelines instead, but weâre not going to make it difficult to keep using the tool you already like if you donât want to switch, and weâre not going to cut you off from some of the best features of Artifactory as some kind of punishment for choosing to stick with Jenkins.
Whatâs that feature Iâm talking about? Build-info.
Build-info is all the information collected by the build agent, which includes details about the build. The build-info includes a list of project modules, artifacts, dependencies, environment variables and more. When using one of the JFrog clients to build the code, the client can collect the build-info and publish it to Artifactory. When the build-info is published to Artifactory, all the published details become visible in the Artifactory UI.
You get access to all of that data right in Artifactory as long as youâre using JFrog Pipelines, the JFrog CLI, or one of the six other CI/CD tools we provide integrations for. Which is six more options than AWS is giving you with CodeArtifact, and a whole lot more context for whatâs going on with your builds.
Return to the index:
