Hi @joris-guex ,

Thanks for the detailed information; I was able to reproduce the error pretty easily thanks to that.

It seems to be happening when parsing a Dependency entry in the .toml file (missing version), but I can't figure out why since the version appears to be there. It also shouldn't cause this beahvior for this particular error.

In any case, we'll get it fixed via PG-3303 in an upcoming maintenance release. !

Cheers,
Alana

Hi @brandon_owensby_2976,

It's a bit confusing, but the message "{name}" is not a valid DeploymentScript identifier for the "global" scope. will occur when:

• a script is being executed in the global context (as this is case here)
• the {name} does not start with global::

I know you mentioned you pre-fixed with global::, but these scheduled jobs can be a bit tricky to test. It's possible that the old record (without global::) was queued up.

To be totally certain next time, I would stop/start the service so that there's nothing that gets queued up.

Thanks,
Alana

@Ashley thanks for letting us know!

Hi @brandon_owensby_2976 ,

Thanks for the feedback, we appreciate it :)

There's definitely a value in building before merging; if you haven't already, I'd check out that feature branch article, as it outlines the pattern we use for it.

In general, the way I would try to configure is:

• consider using a releaseless-build if you don't yet know the release it's targeting
• use a different piepline so it's visually clear; the stages may be Build -> Test -> Merge
• clean up the builds aftewards

That said, this isn't the most popular workflow in BuildMaster, so it may not be the most intuitive to implement or feel a bit clunky.

We don't have a lot of public examples, but the inedo-docs application is the closest to a Gitflow, releaseless type of workflow. Commits to master branch auto-deploy to live site, where as branches can only go to test:
https://buildmaster.inedo.com/applications/136/overview

No idea if that's helpful, but just FYI

Cheers,
Alana

Hi @brandon_owensby_2976 ,

Looks like this is a regression in BuildMaster 2025 from a library upgrade; we will address it via BM-4017 in an upcoming release, either this Friday or the following cycle.

Thanks,
Alana

Hi @pg_user_8607 ,

Nice find with that image; that makes it easier to demonstrate :)

This is unfortunately another "weird docker thing" that would requires a substantial amount of internal model changes to properly address. That's not on our roadmap at this time.

The image you found (inedo/buildmaster:25.0.12) is a so-called "fat manifest" (i.e. a manifest that points to another manifest). As such, there are zero layers (blobs) and thus the sum of all blob sizes is zero.

The 25.0.12 manifest points to e84148156b3e, which is an untagged image. You can see this on the "Sub Images" page:

The /containers page does not show untagged images.

In the past, "fat manifests" were rare - but the default Docker build tools default to create fat manifests, even if there's only one image. It's something we will likely address down the line, it's just not in the roadmap now.

Thanks,
Alana

Hi @brandon_owensby_2976 ,

I'm not sure how easy it will be to replicate that UI and workflow of your current system. It sounds like you're doing some version of "Gitflow", where the "main" branch is "production-ready" and release-candidate builds are "chosen" from that.

BuildMaster uses a different workflow. As you may know, the BuildMaster model uses a Release as a logical set of Builds, with the intent that a single Build within a release will make it to production (final stage). Here's the article that explains is a bit more clearly:
https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Jenkins (and Gitflow) in general does not model Releases in this manner. Instead, it only has "builds", and a build is either a feature branch or a main. And the main build is what eventually gets deployed using a separate job, after a release engineer "picks the build they want" from a list of "main" builds.

The closest way to model this workflow in BuildMaster is to use release-less builds. In BuildMaster, the "Builds" listing will show the branch that is associated with the build, so you can easily see "main" and "branch" builds.

However, this is working a bit against the grain; Releases are a superior workflow model and solve a lot of business problems that Gitflow and "picking from a list of main builds" causes: https://blog.inedo.com/lean-platforms/releases

Here is some notes on our pattern for handling feature branches:
https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches

Cheers,
Alana

Hi @pg_user_8607 ,

Thanks for the bug report; this will be fixed via PG-3296 in the next maintenance release (scheduled next Friday). It was a problem in the redirect to the /log-in page, so of course if you log-in first, the error will not occur.

Cheers,
Alana

Hi @aristo_4359 ,

We didn't make any changes to LDAP/AD in ProGet 2026; the issue mentioned in the post was more of a display/widget issue (from a UI library upgrade).

Unfortunately we don't have enough to go on to help troubleshoot this nor do we have any other users who can reproduce this. In addition, API keys and Active Directory are separate authentication methods altogether.

There were also no changes to API keys... so it's very possible this is something else altogether,
such as a temporary AD lock out or user configuration issue. We see that quite a lot.

Otherwise, since it's only impacting you and we can't reproduce it, you'll have to simplify the reproduction case to isolate exactly what's happening.

I would try upgrading again, and then going to Admin > Security and using the AD test tool. For the API key issue, I would use a tool like Fiddler or Proxyman to capture HTTP traffic, so you can see exactly what requests are being issued and failing.

Cheers,
Alana

Hi @brandon_owensby_2976 ,

Release Numbers in BuildMaster need to be numeric (e.g. 1, 1.2, or 1.2.3), so it's not possible to start a new release number with pr-*. The Release Name can be alphanumeric and does not need to be unique.

When you create a repository monitor, you can select "Only monitor branch when a pull request is open"; this will effectively allow you to create builds when a pull request is created, since the branch will be ignored until a PR exists.

However, the PR number is not automatically captured in the runtime state. In theory, you could query the GitHub API to find the PR by branch name if you really needed it.

Also note that you may find it easier and more reliable to trigger from the GitHub side of things, using the BuildMaster API. That's typically what we see for these more advanced scenarios.

Cheers,
Alana

Hi @david-williams_3389 ,

On Windows, the embedded database is stored under %ProgramData%\ProGet\Database; we don't support changing that path at this time.

Is there a specific reason you'd want to relocate it? The database shouldn't be that big (gigabytes is uncommon) and does not grow that fast (unlike package/content).

Thanks,
Alana

Hi @Ashley ,

We're planning this Friday... though it may not make it. Hopefully!

It's a bit more involved, since it involves calling the separate API instead of the simple API.

Cheers,
Alana

Hi @vdubrovskyi_1854 ,

Thanks for the detailed reproduction information; I debugged/fixed this, and it will be in the next maintenance release of ProGet via PG-3290, scheduled for Friday of this week.

As for the underlying issue, the problem was that there were two composer.json files in the zip file. ProGet was opening build/composer.json instead. I didn't test a work-around, but in theory you should be able to just download the zip file directly, delete build/composer.json from it, and upload it to ProGet.

I also updated the error message to make somethign like this a little easier to track if it comes up again ("An unexpected error occurred: Error parsing "voku-simple_html_dom-716822e/build/composer.json" as a Composer manifest file (Missing required property: name).")

Cheers,
Alana

Hi @jimbobmcgee ,

Very cool!

We did not forget about this, just got a bit behind on feature requests (which this got classified on) with ProGet 2026 coming out.

However, we've added this to our BuildMaster/Otter 2026 roadmap to review and incorporate. We plan to start on that relatively soon, and it may be something we can easily back-port to BuildMaster/Otter 2025.

We'll update once we make progress on this :)

Cheers,
Alana

Hi @Ashley ,

Looking over the code that makes sense; the warehouse API is not used for the /simple/ty request, only the /simple/ty/0.0.0 type of request.

We'll get this addressed via PG-3288 in the upcoming maintenance release

Cheers,
Alana

Hi @Nils-Nilsson ,

We've added this to our ProGet 2026 roadmap; there's an additive feature called "Build Pipelines" that just didn't make it in time for release, so this will fit nicely into that.

FYI the main thing that this new pipeline offers is the ability to create multiple pipelines and assign them to different releases.

Thanks,
Alana

Hi @Valentijn ,

I just checked and that's an expected message.

Can you stop the ProGet service, then navigate to a commandline and run proget.exe run?

That will give detailed console output; in there you may see some messages about HTTP bindings, such as this:

The URL was configured to use HTTPS, but a certificate was not specified.
info: Inedo.Web.BackgroundTaskQueueService[0]
      Background Task Queue is starting.
warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Overriding address(es) 'http://*:8624, https://*:8625'. Binding to endpoints defined via IConfiguration and/or UseKestrel() instead.
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://[::]:8624
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://[::]:8625

Hopefully that will give us a clue.

Thanks,
Alana

Hi @brodie-mclennan_5777,

Thanks for the detailed information on this one; I was able to reproduce this and found two separate issues with build/feed package matching and OSS metadata caching.

These impact multi-file PyPI packages (which are most). Anyway, this is fixed via PG-3284 and PG-3285 in the next maintenance release of ProGet 2026, scheduled for this Friday.

Happy to get you prerelease if you wanted to try it sooner.

Cheers,
Alana

Hi @felfert ,

The /health API endpoint changed in ProGet 2026 and it looks like we forgot to update the pgutil health command and docs.

I just published a new pgutil that will work-around this issue now, and we'll also tweak ProGet's health API a bit to require fewer changes to pgutil via PG-3283.

$ pgutil health --source=https://proget.inedo.com
Checking https://proget.inedo.com/...all OK
Version: 26.0.1.14 (26.0.1.14)

Database: OK
License:  OK
Service:  OK

Alana

Hi @imm0rtalsupp0rt ,

Great, thanks! I'll share the pull request with our technical writing members; they handle the HOWTO type articles and may want to add more screenshots, etc. But that intro paragraph will really help them.

Changing the texts is trivial; it'll be implemented via PG-3278 in the next maintenance release of ProGet 2026. FYI I also changed description too:

Chocolatey Community Packages

Cache and filter packages from the Chocolatey Community Repository (CCR).

Cheers,
Alana