JFrog Artifactory vs AWS CodeArtifact: Promotion Pipelines

This post is a part of a series by JFrog Developer Advocates, comparing JFrog Artifactory to AWS CodeArtifact. You can find the other parts in JFrog Blog on Dev.to.

A simple question: why do you need an artifact repository for?
There are many correct answers to this question, and AWS gives us their take right on the "Getting Started" page of CodeArtifact:

Notice anything missing? You knew it, promotion pipeline!
Over the years of JFrog experience, it emerged as the most important and critical use case. What I mean by that is the repositories in the tool are used as staging areas for artifacts of different maturity: repository/ies for development, repository/ies for testing, repository/ies for staging, etc:

Once you have repositories like maven-stage-local and maven-prod-local, what do you do next? Well, your CI server will deploy the artifacts into the beginning of your pipeline, and after passing the quality gates, your pipeline orchestrator (might be your CI server, but might be another tool, like JFrog Pipelines, for example) will promote the artifacts from one repository to another:

How this promotion is done? On a surface – easy. You just move (or copy) the artifacts, and annotate everything you did in the metadata.

The first question is to move or to copy? It's a matter of personal preference. With Artifactory it doesn't matter, really, since the artifacts are deduplicated across the entire platform, so you don't pay for having extra copied (in storage or money).
In CodeArtifact you will pay for every copy you hold (I didn't find any evidence suggesting otherwise), so you'd prefer moving? Well, you can't, there is no "move artifact" action.

Well, this is annoying, but at the end of the day it does the job, right? You get your artifacts from one repo (dev) to another one (staging)? Kinda. What about the metadata? What was promoted? Which set of artifacts? Why? Who moved it? Why? Based on what quality gates? This information is critical both for decision making and for investigation if (when?) shit hits the fan. 

Promoting (moving or copying) single artifacts is okay, but what you really want to promote is a build – a set of artifacts and metadata, and you want to generate metadata about the promotion.

So, to summarize, here's what I miss in CodeArtifact repository management at the moment:

• A clean way to implement a pipeline with quality gates (sets of repositories for different maturity).
• A way to atomically promote groups of artifacts and metadata (a build) while leaving the necessary paper trail of metadata.
• Promotion by movement.

Needless to say, you have them all in JFrog Artifactory.