Inedo Community Forums Forums
    • Recent
    • Tags
    • Popular
    • Login
    1. Home
    2. atripp
    3. Posts

    Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

    If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

    atrippA Offline
    • Profile
    • Following 0
    • Followers 3
    • Topics 1
    • Posts 1,947
    • Groups 2

    Posts

    Recent Best Controversial
    • RE: SBOM Dependency Tree is lost when importing and exporting

      Hi @christian-georg_5533 ,

      Thanks for sharing the additional context, that makes sense.

      You are correct -- ProGet is a package repository with SCA as a value-added feature. Most of our users create SBOM because they are required to due to regulations, and but don't find much use outside of that :)

      Of course we're always interested in expanding features but we aren't really striving for the "central SBOM Repository" use case now. We'll see if there's more demand down the line, feel free to share more information (other products, tools) sinc eit's always good to think about future versions of the product!

      Cheers,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: SBOM Dependency Tree is lost when importing and exporting

      Hi @christian-georg_5533 ,

      Thanks for sharing this; this behavior is expected.

      ProGet is not a "SBOM Document Repository" (e.g. like Dependency Track), but instead models Projects & Builds for Software Composition Analysis (SCA). A Build is comprised of Packages (which should be stored in Feeds in ProGet), and "importing an SBOM document" is one way to create a build/package dataset.

      Note that a build in ProGet will often be comprised of multiple SBOM documents, especially for web applications where like npm + .NET is used.

      ProGet can "export" a build as an SBOM, and some of the information from the imported document will be used. However, our SCA model does not model a dependency tree, so it's not possible for this kind of information to be output or preserved.

      That could be something we consider as a feature request, but we'd need to start with the "SCA model" (i.e. Builds + Packages) first, and try to understand why modeling a dependency tree relationship is beneficial.

      The main idea I can think of is to "reduce noise from vulnerabilities", but that's a core feature of ProGet 2026 (upcoming!) so I'd check that out first, and see if it makes sense still.

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Increased Incorrect Classification of Security Vulnerabilities

      Hi @geraldizo_0690 ,

      I think the best way for us to proceed with this investigation is to get a copy of your database backup. And as a bonus, we'll validate your database to make sure the upgrade to ProGet 2026 and the new vulnerability management features work nicely :)

      I created a secure public link for you, which you can access in this ticket that I've created for you: https://my.inedo.com/tickets/view?ticketNumber=EDO-12790

      Just let us know once you've uploaded the BAK file, and we'll take a look and figure it out from there.

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Unhandled exception in execution #xxx: 42702: column reference "DatabasePath_Text" is ambiguous

      Hi @cole-brand_2889 ,

      In general, that error message means some kind of code problem. Like, using "DatabasePathText" on a multi-table join without specifying which table/alias it belongs to.

      However given the queries (see below code), I don't see the problem. I haven't seen the error on PostgreSQL... so that must mean it's Aurora Postgres specific?

      According to ChatGPT, "Aurora PostgreSQL is stricter about recordset functions and want a relation alias before the column definition list.", but who knows if that's true. About the only way to test this theory is to modify the function code in your database. I've pasted it below, and you should be able to just run that to "edit" the code.

      It'll get updated during any normal upgrade/downgrade, so no real worry.

      The first change suggested was to add a BPT here:

          WITH BlobPackages_Table AS (
              SELECT * FROM jsonb_to_recordset("@BlobPackages_Table") AS BPT("DatabasePath_Text" VARCHAR(200), "PackageVersion_Id" INT)
          ),
      

      I don't see how that could work, but who knows. Another suggested change was this:

          WITH BlobPackages_Table AS (
              SELECT * FROM jsonb_to_recordset(COALESCE("@BlobPackages_Table", '[]'::jsonb)) AS BPT("DatabasePath_Text" VARCHAR(200), "PackageVersion_Id" INT)
          ),
      

      Although, I also don't believe that word work, since the @BlobPackages_Table would not be null. But again who knows.

      Anyway... that's where I would start. It might be something else altogether, but I can't see it and I guess my ChatGPT prompt didn't spot it either.

      CREATE OR REPLACE PROCEDURE "DockerBlobs_RecordScanData"
      (
          "@DockerBlob_Id" INT,
          "@BlobInfo_Configuration" XML,
          "@BlobPackages_Table" JSONB
      )
      LANGUAGE plpgsql
      AS $$
      BEGIN
      
          IF "@BlobInfo_Configuration" IS NULL THEN
              DELETE FROM "DockerBlobInfos" WHERE "DockerBlob_Id" = "@DockerBlob_Id";
          ELSE
              INSERT INTO "DockerBlobInfos" ("DockerBlob_Id", "BlobInfo_Configuration")
                   VALUES ("@DockerBlob_Id", "@BlobInfo_Configuration")
              ON CONFLICT DO
               UPDATE SET "BlobInfo_Configuration" = "@BlobInfo_Configuration"
                    WHERE "DockerBlob_Id" = "@DockerBlob_Id";
          END IF;
      
          UPDATE "DockerBlobs"
             SET "LastScan_Date" = CURRENT_TIMESTAMP
           WHERE "DockerBlob_Id" = "@DockerBlob_Id";
      
          WITH BlobPackages_Table AS (
              SELECT * FROM jsonb_to_recordset("@BlobPackages_Table") AS ("DatabasePath_Text" VARCHAR(200), "PackageVersion_Id" INT)
          ),
          packagesToRemove AS (
              SELECT *
                FROM "DockerBlobPackages" DBP
                LEFT JOIN BlobPackages_Table BPT 
                       ON BPT."DatabasePath_Text" = DBP."DatabasePath_Text" 
                      AND BPT."PackageVersion_Id" = DBP."PackageVersion_Id"
               WHERE DBP."DockerBlob_Id" = "@DockerBlob_Id" 
                 AND BPT."PackageVersion_Id" IS NULL
          ),
          deletes AS  (
              DELETE FROM "DockerBlobPackages" DBP
                    USING packagesToRemove PTR
                    WHERE DBP."DockerBlob_Id" = "@DockerBlob_Id"
                      AND DBP."DatabasePath_Text" = PTR."DatabasePath_Text" 
                      AND DBP."PackageVersion_Id" = PTR."PackageVersion_Id"
          ),
          newBlobPackages AS (
              SELECT BPT.*
                FROM BlobPackages_Table BPT
                     LEFT JOIN "DockerBlobPackages" DBP 
                            ON DBP."DockerBlob_Id" = "@DockerBlob_Id" 
                           AND BPT."DatabasePath_Text" = DBP."DatabasePath_Text" 
                           AND BPT."PackageVersion_Id" = DBP."PackageVersion_Id"
               WHERE DBP."PackageVersion_Id" IS NULL
          )
          INSERT INTO "DockerBlobPackages"
               SELECT "@DockerBlob_Id",
                      "DatabasePath_Text",
                      "PackageVersion_Id"
                 FROM newBlobPackages BPT;
      
      END $$;
      

      // also I do realize the json input is not a great way to handle this, but it's how we needed to port a few things from SQL Server to maintain parity in behavior

      Let us know if you find anything! Thanks, Alana

      posted in Support
      atrippA
      atripp
    • RE: Deploying a Docker Image via Kubernetes with a yaml file

      Hi @brandon_owensby_2976,

      I'm afraid we don't have a lot of great documentation / information on how to deploy Kubernetes using BuildMaster. The existing extension is quite old and reflects a pre-Helm approach where Kubernetes resources were deployed directly via raw manifests.

      These days, Helm charts are the standard way to package Kubernetes applications. A chart contains templated manifests along with default configuration (values.yaml) that can be overridden per environment.

      Once you have a chart, you typically deploy it with a command like:

      helm upgrade --install myapp corp/app -f values.yaml
      

      Additional overrides (like your override.yaml) can be layered in as needed. In theory, that's where a BuildMaster configuration file would come in, and BuildMaster would also run the upgrade commands.

      However... Helm isn't really run outside of development environments. Instead, most teams use a GitOps-based tool (i.e. Argo CD or Flux), which in turn use Helm to continuously "sync" whatever's in Git with what's running in the cluster.

      The idea is that the "deployment state" is maintained in Git and doesn't need to be triggered from an external release system. In other words, a production "deployment" is done by issuing a commit.

      Because of this, pipeline-driven deployment tools BuildMaster just popular for Kubernetes workflows. We've seen competitive tools try, but they get a lot of pushback from the end-users (i.e. Kubernetes engineers) and as a result don't see much adoption.

      In my opinion, this is like 7 layers of unnecessary complexity (let alone error-prone) and a basic Docker deployment covers like 99% of use cases... but that's not where the market is.

      Hope that helps clarify things a bit, let us know what you find.

      Cheers,

      Alana

      posted in Support
      atrippA
      atripp
    • RE: Not able to delete published docker images

      Hi @parthu-reddy ,

      This does not appear to be a "fat manifest". Two other things are coming to mind.

      First, are these referenced in any helm charts? If so, they won't get removed unless you delete the helm chart first.

      Second, how about trying a separate policy, "Delete untagged manifests"? That should clear out these images.

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Amazon.S3.AmazonS3Exception: Please reduce your request rate.

      Hi @cole-brand_2889 ,

      Wow, I didn't realize that S3 rate-limited like that!! That's good to know.

      Unless this is something that could be configured as an advanced SDK switch in the S3FileSystem, then I don't think there's much that could/should be done in the ProGet or extension code.

      After searching the error (and seeing this very post on the first page of Google 😂), this just seems to be endemic with S3; there's no published rate limit, and even in AWS official blog article the only solutions seem to be "follow the error message and reduce your request rate".

      There's probably something you can do do on the load-balancer side of things... reducing concurrent requests, etc.

      Let us know what you find!

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: ProGet Connector Filters Performance

      Hi @davidroberts63 ,

      While connector filters were never really designed to replace the "approved packages" workflow, we've seen many users do exactly that over the years, yielding hundreds of entries.

      It's not exactly a use case we recommend, as one of the big benefits of the approved packages flow is to prevent "instinctively upgrading dependencies" yielding in regressions. But, if you're already effectively doing that through automation, then I suppose you already know the risks :)

      From a performance standpoint, it shouldn't make a notable impact. Those have been optimized for quite some time now.

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Incorrect published date handling breaks min-release-age for npm feeds

      Hi @aleksander-szczepanek_3253 ,

      If you navigate to Admin > Advanced Settings and check "Use Connector Publish Date", then this will behave as you expect. Note that you will need to delete already-cached packages.

      This will be default behavior in ProGet 2026+

      Cheers,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Transfer License: Active On Two Servers Temporarily

      Hi @denis-krienbuehl_4885 ,

      Thanks for checking; for a short-term like this no problem!

      Cheers,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Supported Database for ProGet HA Installations

      Hi @EnterpriseVirtualization_2441 ,

      We do not recommend using SQL Server Availability groups..

      For a product like ProGet, a single database node is all that's required -- and it's strongly recommended.

      There is no practical benefit to a clustered database here - on the contrary, it makes the product slower, less stable, and more costly/complex to maintain. As such, InedoDB does not support clustering.

      Cheers,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Support for kubernetes-based deployment of ProGet and InedoDB?

      Hi @jeff-williams_1864 ,

      ProGet for Linux (Docker) is fully supported. You deploy it how you'd like, and many customers use container orchestration platforms like Kubernetes with no problem.

      However, we only provide step-by-step instructions for Docker. This is intentional, as these platforms are quite complex and require a lot of skills to configure, maintain, and troubleshoot.

      While we try to help support "platform issues" on Windows (i.e. everything from permissions to Domain configuration), that's a lot more straightforward for us to support -- and Microsoft can pick up the slack (e.g. a failed Windows update, etc).

      So long story short, if you are comfortable with Kubernetes/Openshift, feel free to use it. But otherwise, we don't want ProGet to be our users' "first Kubernetes" experience :)

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: https://docs.inedo.com/docs/proget/api/pgutil#sources ~/.config/pgutil/ pgutil.config correction

      Thanks for pointing that out @rcpa0 ! I've just updated the docs now.

      posted in Support
      atrippA
      atripp
    • RE: Supported Database for ProGet HA Installations

      Hi @jeff-williams_1864 ,

      You mentioned that you're "using the embedded database at the moment", which I take to mean that you're not using a separate SQL Server container image.

      The In that case, the only options for a clustered installation is using InedoDB (recommended) or an External PostgreSQL (not recommended).

      If you were using SQL Server, then SQL Server would be supported for a clustered instance as well. However, we are moving away from SQL Server, so we definitely wouldn't recommend it on a new installation.

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Proget is unable to download Maven packages that use a nonstandard versioning scheme

      Hi @devops-user @joshua-mitchell_8090 ,

      Thank you so much for testing! We'll merge this in via PG-3251 in tomorrow's maintenance release.

      As for the other error, it's technically unrelated - but that package has such a long "compliance analysis report" that it's getting truncated in the database cache. PostgreSQL complains about that, SQL Server silently does it. Anyway w'ell fix via PG-3250 perhaps in tomorrow's release as well.

      Cheers,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Docker _catalog and tags calls do not respect tokens

      Hi @Stephen-Schaff ,

      The Docker API does not use API keys but a ticket-based system (i.e. docker login). Here is how to use it:
      https://docs.inedo.com/docs/proget/docker/semantic-versioning#example-powershell-script-to-authenticate-to-docker

      We added some kind of support via PG-3206 in ProGet 2025.20, though it was only intended to address self-connectors to Docker registries. I do'nt know how well it will work here.

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Composer feed: metapackage is not saved as a local package

      Hi @vdubrovskyi_1854 ,

      Unfortunately this is just how composer works; it never requests the metapackage from the server (i.e. ProGet) nor does it upload the composer.lock file to ProGet.

      There is obviously no way for ProGet to "guess" what metapackages you may want. Obviously, ProGet does not automatically download/install every metapackage from the upstream repository. That's obviously not behavior anyone would want, and we will not add it to ProGet.

      You have two options:

      1. Modify the behavior of composer to request these packages from ProGet,
      2. Writing a script to parse your composer.lock and then download and/or promote those files within ProGet

      Hope that helps,

      Alana

      posted in Support
      atrippA
      atripp
    • RE: Composer feed: metapackage is not saved as a local package

      Hi @vdubrovskyi_1854 ,

      I'm not an expert on how Composer handles packages, but so far as I can tell the behavior you’re seeing is expected and is how metapackage types are handled.

      A metapackage does not contain any files and is not installed into the vendor/ directory. It exists only to define dependencies on other packages. There is no contents in the package and thus, there is nothing for Composer to fetch.

      Because of this:

      • It will appear in composer.lock as part of dependency resolution
      • It will not create a directory under vendor/
      • The content itself is not be fetched (downloaded) from Composer
      • Only the Composer API is queried

      ProGet can only cache a package when a download/fetch occurs. Since metapackages are not fetched, there is nothing to cache.

      When you downloaded manually, you are deviating from Composer’s normal install behavior for metapackages -- so that's why it appears.

      In summary, this behavior is expected and not an error in ProGet. Unfortunately there's no way for ProGet to cache these packages, since Composer never downloads them.

      Hope that helps,

      Alana

      posted in Support
      atrippA
      atripp
    • RE: [Buildmaster] Add queryable custom properties on a deployment level

      Hi @Anthony,

      I'm afraid not; the deploymentinfo is part of the BuidMaster API, and it's effectively reading data from the database that you'd otherwise see in the UI. Its fairly "disconnected" from runtime execution.

      The only persistent (i.e. outside of runtime) variables are going to be configuration (i.e. Build-scoped) variables. I suppose one thing you could do is define multiple build variables (e.g. $MyTarget1=value, $MyTarget2=value2).

      You could also store a map variable on the build, like %MyMap = %(MyTarget1: value, MyTarget2: value2) -- although that might involve a bit of awkward OtterScript to get working.

      It's not a use case we designed for.

      Cheers,
      Alana

      posted in Support
      atrippA
      atripp
    • RE: Proget is unable to download Maven packages that use a nonstandard versioning scheme

      Hi @devops-user ,

      No problem, I just pushed Release 2025.25-rc.1.

      It's based simply the 2025.24 release with the Maven patch added in. You can install like this:
      https://docs.inedo.com/docs/installation/windows/inedo-hub/howto-install-prerelease-product-versions

      Thanks,
      Alana

      posted in Support
      atrippA
      atripp
    • 1 / 1