inedo-engineer

Hi @it_9582 ,

What version of ProGet are you using? There was a recent regression (PG-3204) that was fixed in ProGet 2025.19 with regards to symbol server. S hopefully upgrading will fix the issue.

Cheers,
Alana

Hi @paul-moors_5682 ,

We'll definitely keep an eye on this after ProGet 2026; we're doing some big improvements for vulnerability management, which will probably push more folks out of the Approval Workflow.

One thing I like about an in-built workflow is that it demos really well and makes it so much easier to see/understand how an approval workflow could work. While I personally love the idea of "approved packages only", it's so hard to recommend that workflow in practice.

Anyway, let us know how your approval-only journey goes. We tried it internally here and it was a flop... just Microsoft's growing dotnet dependencies alone made it impractical.

Cheers,
Alex

Hi @certificatemanager_4002 ,

Check out our Licenses for Non-production / Testing Environments for the full details.

But if its a short-term migration testing scenario, then using an existing or trial key is fine. For a long-term environment, a separate license is required.

-- Dean

Hi @Valentijn,

We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available.

Thanks,
Rich

Hi @adoran_4131 ,

Keep in mind that ProGet and Artifactory work differently; Artifactory is basically a "file server" and is just does "blind proxying" of HTTP requests. That's why it doesn't matter what URLs you put in. ProGet, on the other hand, is a package server, and will index the remote repository first. That's where things are failing right now.

It's failing because the index file is not being found based on the input. This is what a Debian repository is supposed to look like:

dists/
    {distribution-name}/
        Release
        Release.gpg
        main/
            binary-amd64/
                Packages
                …
pool/
    main/ …

So, the distribution-name is incorrect. I thought it might be binary based on the instructions, but these URLs are both a 404:

https://pkg.jenkins.io/debian-stable/dists/binary/Release
https://pkg.jenkins.io/debian-stable/dists/binary/InRelease

So, it must be something else. It's whatever apt is sending by default, I guess?

Anyway, if you can find what distribution it should be, then it will work. Perhaps consider just doing something like this:

sudo apt update -o Debug::Acquire::http=true

That will show you the HTTP requests being made, and you can see exactly the URL for the Release file, which you can then use to reverse-engineer the distribution name.

Let us know what you find!

Hope that helps,
Steve

Hi @scusson_9923 ,

Looks like this is a bug in not overriding the job/execution status; the force normal statement should make it "green" and a normal execution status. Anyway we'll get it fixed via OT-524.

Cheers,
Steve

Hi @adoran_4131 ,

It looks like the 404 error is occurring while trying to download the Release file (i.e. the index) for the repository. The file is being downloaded from this URL:

{connector-url}/dists/{distro}/Release"

And that URL is returning a 404. So make sure you are entering the correct distro in the connector.

Thanks,
Steve

Hi @paul-moors_5682 ,

Thanks for sharing this idea; it's interesting idea and is actually something we talked about internally over the years.

However, after several conversations with a few customers who used the Package Promotion Workflow, they wouldn't find any value or use the feature. The reason is, they already have workflow tools (ServiceNow, JIRA) that document/automate SOP like these, and some will even do a quick API call once the package is approved.

In other words, everything happens in the workflow tool -- which is used for every other SOP from architecture review to vacation requests.

Now just to comment on the "best practices" part; we are working on revising our practices, but we don't consider "package promotion" the best practice anymore. Instead, we consider it the "option with the most control (and highest cost)".

If that level of control is not needed by the organization, then it shouldn't be used -- given the explosion of dependencies (1000+ for the average npm project), it's a lot of process to maintain. A lot of customers (military contractors, etc) are used to that level of process/control and it's fine.

But if you try to institute this at an organization without this process-heavy culture, you'll get a "rebellion" and just see shadow-IT and bypassing of these rules. And they won't get fired or even scolded.

And that brings us back to why no one seems to want this type of system -- companies with this level of process use ServiceNow/JIRA for everything already.

Cheers,
Alex

Hi @matthias-schmitz_2037 ,

The "Signature ... was created after the --not-after date" message is coming from sqv (Sequoia-PGP verifier), which newer versions of APT use for signature verification.

It almost always indicates a system clock problem on the affected machine, not a repository problem, and often means "The system clock is behind the signature creation time."

So bottom line, I would check the clocks to make sure they are accurate.

Thanks,
Steve

Hi @scusson_9923 ,

The message is expected, but you should see scriptExists: false written at the end, and aNormal status (i.e. green) for the execution.

Is that not the case?

Thanks,
Steve