Feature Request / Discussion: Restricting Build Promotion to Forward-Only (Prevent Backward Promotion)

fabrice.mejean

Hi everyone,

I’d like to open a discussion regarding the Build Promotion feature in ProGet.

Currently, as far as I can see, ProGet allows users to promote a build from any stage to any stage. While this offers a lot of flexibility, it also introduces a significant risk: the ability to promote a build "backward" (i.e., downgrading or promoting to a lower stage/previous environment).

The Problem

In many workflows, build promotion should strictly be a one-way street (forward-only). If a team needs to reproduce a production bug, they might want to deploy/promote a specific older build to a non-production environment (like Staging or QA). However, because the tool allows promotion from any stage to any stage, there is a high risk of accidentally performing an unwanted promotion (such as pushing an older/wrong version into a higher pipeline stage by mistake, or mixing up the promotion flow).

Allowing backward promotion bypasses the logical progression of a standard release pipeline (e.g., Build ➔ Integration ➔ QA ➔ Production).

Proposed Evolution

I believe ProGet should offer an option (or a default behavior) to restrict build promotions to forward-only. Once a build reaches a certain stage, it should not be allowed to be promoted "backward" to a prior stage in the pipeline.

️ Crucially, this restriction should apply to both the Web UI and the API to ensure that automated scripts or manual actions cannot bypass this safety guardrail.

This would:

Prevent accidental misconfigurations or human errors during hotfixes and debugging phases.
Ensure strict adherence to the defined pipeline lifecycle.

What are your thoughts on this? How do you currently handle this risk in your pipelines, and would you find such a restriction useful in ProGet?

Looking forward to your feedback!

apxltd

Hey @fabrice-mejean ,

Thanks for the thoughtful feature request!

My somewhat rhetorical question is.... don't you have another tool that manages pipeline lifecycle? Doesn't that tool just handle promotion and then "call into" ProGet.... and thus, ultimately, does it really matter if ProGet's information is wrong?

But here's the long explanation / rambling...

--

So we actually implemented a whole new feature for ProGet 2026 called "build pipelines", but then I scrapped it because it just didn't "feel right".

The major highlights were this:

add concept of "Pipelines", which are a collection of stages; the current stages would be converted into the Default pipeline
add "enforce stage sequence" on a Pipeline, which would allow you to just promote without selecting a stage and error if you tried otherwise
add concept of "Releases", which group related builds together under a common release number and Pipeline (basically the BuildMaster definition)

This would allow you to do a workflow something like this:

pgutil builds releases create --number=1.0.0 --pipeline=major
pgutil builds scan --build=1 --release=1.0.0
pgutil builds promote --build=1 --release=1.0.0 # build -> test
pgutil builds promote --build=1 --release=1.0.0 # test -> qa
pgutil builds promote --build=1 --release=1.0.0 # qa -> prod

Since the build was promoted to the last stage, the release status would become "deployed" or something like that. By default, this would "archive" the previously deployed release, which would hide all those related builds from the dashboard.

This model made sense to me, as a single project/application often has multiple releaes and multiple deployment pipelines, and this kind of modeled that.

That said, the big issue I have is that "Releases" seem to be a foreign concept to many organizations; they simply produce a stream of "builds" and then someone "picks one" to deploy. So, it just feels like we're introducing a concept they don't use.

And then I thought... what exactly would we be solving here? Is anyone actually looking at "stages" or "pipelines" in ProGet? Don't they have some other tool for this? Why are we even modeling these things visually?

The more I thought about it, I kept circling back to "main value" of stages is "issue creation" and "retention" --- not "visualization". So I thought, maybe we should just pgutil builds audit generate issues? Does anyone use issues anyways? .

And then I kinda gave up after that

Anyway, I'd still like to "do something" here, but I'm not sure I'm "connecting the dots" just yet.

There are a few recurring themes users talk about:

Docker container images and the relation to sCA/covernance
Package-based applications (e.g. NuGet for OCtopus deploy, Universal Packages)
Library packages

I can't help but wonder if we can adapt the SCA Builds/Projects to encompass these ideas a little better. Libraries obviously can't have a SBOM (they have dependency ranges instead), but there's gotta be "something" we can do here.

I do feel I'm rambling here, but if we're going to do something, it should be an opiniated approach that introduces a new/better way to solve problems without a lot of friction.

Personally I think visualization is huge, but what's the visuzliation problem we can solve with our tools

Thanks,
Alex

fabrice.mejean

Hi Alex,

Thanks for this very detailed and open answer! It’s great to see your thought process, and I’d love to share our perspective on these points.

1. The Importance of the "Production" Stage & SCA

To answer your rhetorical question about why ProGet's information matters: for us, the "Production" stage is actually the most critical one.

The main reason is SCA (Software Composition Analysis). ProGet is our source of truth for what is currently live. Having an accurate, reliable SCA report of what is actually in production is vital for our security and compliance teams. If a "backward" promotion happens by mistake in ProGet, it corrupts this data, and our production SCA reports become incorrect. That is the core driver behind my request: keeping the Production stage clean and trustworthy.

2. Specialized Tools vs. "All-in-One" Platforms (Siloed CI/CD)

You are absolutely right that we (like many others) will soon be consolidating data from various parts of our system to build a global, unified dashboard of our CI/CD pipeline, which is currently scattered across multiple tools.

However, even though "all-in-one" platform tools (like GitLab or GitHub) exist, they tend to do a little bit of everything but master none. They are generalists. We believe there will always be a need for highly specialized, robust tools like ProGet to act as the ultimate source of truth for packages and builds. That’s why we want ProGet's state to be as foolproof as possible.

3. The Complexity of "Pipelines" and "Releases"

Regarding your scrapped 2026 "build pipelines" feature: you made a very good point. Introducing a heavy "Release" concept might indeed go too far for ProGet and add unnecessary friction, especially since many organizations have complex scenarios (for instance, having multiple different versions of the same product running in production simultaneously). A rigid pipeline model makes this hard to represent.

This is why a simpler, "opinionated" safety guardrail—like just preventing backward promotion (or making stages "forward-only")—might be a lighter, more elegant way to solve the problem without over-engineering a full pipeline manager.

4. Let's Connect!

If you are interested, Alex, I would be more than happy to send you an email with more details about our tooling ecosystem, how we integrate ProGet, and what our workflows look like. It might help you "connect the dots" with real-world use cases as you think about the future of ProGet.

Let me know if you'd like that, and what the best email address would be to reach you!

Best regards,
Fabrice

apxltd

Hi @fabrice-mejean ,

Thanks so much for the detailed information and offer to connect further! Very interested in that and I will definitely take you up on that :)

Please give me a little time for that; I've got some travel coming up and then a bunch of other things... so I'd like to connect when I can really focus on some of these future things.
.
Cheers,
Alex