administrators

Hi @jeremy-oaks_9309,

After digging into this further, there are a handful of issues that have all hit here. Before I dive into these, is there a reason you chose to use InedoDB over using the embedded database? Our guidance is when using a single ProGet container, use the embedded database. InedoDB is only recommended to be used with clustered installations of ProGet.

In your case for using InedoDB and ProGet, there were basically 3 main issues that occurred.

Issue 1:
Your docker compose file is not quite correct. You currently have your volume mappings backwards which will cause your data to not be persisted through restarts. This is also why when you updated the the pg_hba.conf file, it did not persist. I should also point out there was a typo in our DockerFile, which pointed to the wrong directory for an InedoDB volume path. This is fixed in InedoDB 17.10.2. We also updated our InedoDB Docker Installation Docs to include the volume as well.

Here is a modified version of your docker compose that will fix these issues:

services:
  inedodb:
    image: proget.inedo.com/productimages/inedo/inedodb:17.10.2
    container_name: inedodb
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - /mnt/volume_nyc1_proget/postgres:/var/lib/inedodb

  proget:
    image: proget.inedo.com/productimages/inedo/proget:26.0.5
    container_name: proget
    restart: unless-stopped
    depends_on:
      - inedodb
    ports:
      - "8634:80"
    environment:
      PROGET_POSTGRES_CONNECTION_STRING: Host=inedodb;Port=5432;Database=proget;Username=inedodb;Password=<REDACTED>
    volumes:
      - /mnt/volume_nyc1_proget/proget/packages:/var/proget/packages
    deploy:
      resources:
        limits:
          memory: 2g

Issue 2:
The default for pg_hab.conf was too restrictive. This was actually updated in the Windows installer, but not in the inedodb create --name=proget command. This has now been fixed in InedoDB 17.10.2 and it will work out of the box. With that said, it is stored in a persisted volume, so changes will stay in affect. The other part of this is that when create a database, the container needs to be restarted. We have now added a message in the inedodb create command to restart the container.

Issue 3:
The connection string confusion. This is a side effect of Docker. When we generate the connection string in InedoDB, we use the get host name command from within the container. That hostname does not match the container name or network alias of the InedoDB . We have now added a warning when creating a database in InedoDB on Docker that you may need to update the host in the connection string.

With all those addressed in docs and InedoDB 17.10.2, you should be good to create a new ProGet instance with InedoDB. If you have already started adding packages using your existing setup, I would be worried that your database and package files are not persisting through restarts. I would recommend:

1. Set up a new instance using the DockerFile I used above and a trial key
2. Import your packages from that instance to the new instance
3. Shut down you old instance and move the license key to the new instance

I know this is kind of long, so if you are confused on anything or have any other questions, please let me know!

Thanks,
Rich

Hi @brandon_owensby_2976,

Yes, that actually does wire things up with OtterScript, though I just realized I forgot to include a sample for how to actually invoke that script from OtterScript...

PSCall2 MyScript.ps1
(
    Parameters: %(inputvalue: Hello, resultingtext: outputvar)
);

Log-Information MyScript returned $outputvar;

The Parameters argument is meant to handle anything declared as an input/output value in the script's header. Note that for outputs you actually supply the name of the OtterScript variable to assign as the parameter value. For the record, I agree that this is all very confusing and we could certainly do a better job in the UI and docs. I believe the original goal when we added PSCall2 was to make the script parameters more discoverable, but at least as it works now, it has had the opposite effect.

That crazy stuff with the prefix is the mechanism it uses behind the scenes to capture output values that are declared in that parameters header or in the OuputVariables argument.

Does using this kind of header and PSCall2 invocation work at all for you? There's other things that could go wrong with marshalling values to/from PowerShell, but this ought to at least get you outputs without having to jump through those extra hoops.

-Greg

Hi @jeremy-oaks_9309,

Thanks for bringing this to our attention. This looks like a change will will need to make to the InedoDB container. Let me do some digging and I'll have an update for you soon.

Thanks,
Rich

Hi @brandon_owensby_2976,

You're right that this is not very intuitive, and there are some outstanding issues we intend to fix in BuildMaster 2026. Generally, the best way to get all of this wired up right now is to have an Augmented Help header in the PowerShell script like this:

<#
.SYNOPSIS
    Appends world.

.AHPARAMETER inputvalue
    Input string

.AHPARAMETER resultingtext(output)
    Will be set to the resulting text

#>

param ([string]$inputvalue, [ref]$resultingtext)

$resultingtext = $inputvalue + " world" 

The key here is the [ref] specifier in the param block and the (output) specifier in the .AHPARAMETER augmented help header above.

For scripts without a param/Augmented Help header, you should be able to use the InputVariables and OutputVariables parameters of PSCall2 instead.

This is unfortunately missing from the docs at the moment, but before getting that updated I'd like to see if we can streamline or improve this to make it more intuitive.

Does this help at all? We're happy to work with you to improve this before the 2026 release.

Thanks!
Greg

Hi @andreas-unverdorben_1551 ,

I'm afraid this is a problem with our upstream source (GHSA). Long story short, the datafile is incorrect and does not specify a range.

We do not have any plans to build a system/module that allows us to "override" data in the upstream datasources at this time, so the only way we can really address it is by fixing the upstream source.

I believe the best route to do that would be to submit a pull request to the GHSA repository against the related datafiles (e.g. GHSA-4r6h-8v6p-xvw6.json)

In this case, they are missing a "fixed" event in the range:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            }
          ]
        }
      ]

Here's what it needs to look like:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": " 0.19.3"
            }
          ]
        }
      ]

Thanks,
Steve

Hi @brandon_owensby_2976 ,

You can configure release settings on an application-by-application basis under the Settings tab. In this case, you'd set Release Usage to be Optional or Disabled.

If Release Usage is set to Required, users must select a release when creating a new build; this was the deefault in older versions of BuildMaster.

https://docs.inedo.com/docs/buildmaster/modeling-your-applications/buildmaster-releases

Cheers,
Steve

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

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

@Nils-Nilsson excellent, let us know as you have other feedback too! This is definitely an area we intend to keep improving in throughout ProGet 2026+

Hi @carl-westman_8110 ,

Thanks for sharing that. This isn't a symptom of "server overload" that we've seen before.

The error you shared is occurring on Feeds_GetFeeds, which is definitely not an intensive query, and I would not expect that to be timing out at all. It's just SELECT * FROM [Feeds].

However, that's a similar symptom to the "AzureSQL resource throttling" that we've seen on other users: another query is being throttled (for example, something that joins on [Feeds]), and that is causing a cascading impact on other queries.

We don't have enough information to say that's the case here. But, an easy way to test would be to up your DTUs substantially.

Otherwise, the next troubleshooting step is to try to identify the cause of the timeouts, which involves looking at HTTP Access logs and jobs occurring around the same time under Admin > Scheduled Jobs.

Thanks,
Steve