Hi @a.sieger ,

I would push back on that "hard requirement" because it doesn't make any technical or business sense, and will only lead to support headaches just like this.

There is something wrong with your PostgreSQL server configuration, perhaps permission related, that's causing the database to not be created. The error cannot be logged in the database because it doesn't exist.

I would delete the database and start again, but verify you've created the database exactly as specified using the exact version supported:
https://docs.inedo.com/docs/installation/postgresql#external-postgres

Things like improper locales will cause errors.

Then, don't run ProGet detached (i.e. ommit -d) so you can get the console logs. That's where you will see database errors. You can also run the upgradedb command instead:
https://docs.inedo.com/docs/installation/linux/installation-upgrading-docker-containers#upgrading-the-database-only-optional

Please let us know what you find!

Hope that helps,
Alana

@forbzie22_0253 yes it's supported, but please note we are moving away from SQL Server to PostgreSQL, so you should consider migrating (Admin > Database)

Hi @a.sieger ,

Please note that we do not recommend an external PostgreSQL database. It performs slower, costs more to maintain, has a higher chance of outages, and tends to cause support headaches down the line. The database primarily stores package metadata and application configuration, doesn't take up much disk space, and it's not the business data that your DBAs would own.

That being said if you really insist on using one, then please refer to the Database Connection String section on the page you linked.

For the non-embedded PostgreSQL database backend, you will need to specify a «inedo-product»_POSTGRES_CONNECTION_STRING environment variable instead.

So you need to use PROGET__POSTGRES_CONNECTION_STRING

Thanks,
Alana

Hi @daniel.mccoy_4395 ,

Actually, developer experience is a big reason we don't recommend using Download Blocking. A 400 error provides no real context. Developers can see something is wrong, but not how serious it is or what to do next.

First and foremost, an unlisted package should not be noncompliant. An author may decide to unlist their package for any number of reasons, including simply not wanting too many versions to show up in a list.

This would mean that, all of a sudden, a build deployed to production can suddenly be considered as noncompliant just because an open source author arbitrarily flipped a switch on NuGet.org. That's not to say you should ignore the unlisted flag, but you should definitely not put it at the same categorization as a GPL3 license or severe vulnerability.

"Compliant with Warning" could be a more appropriate status here, but keep in mind that developers swill naturally upgrade dependencies as they do platform updates, so it may not even be worth worrying about. Especially if it leads to constant warnings -- in that case, warnings become meaningless.

Noncompliant packages should be rare for the same reason. If noncompliant can be determined by an OSS author's whims, then it really caries no meaning and no one (especially your developers) will understand/appreciate what it means.

As for the workflow to use, we recommend running pgutil builds scan when that pull request is run. That will not only put the build in ProGet, but it will produce a text report with warnings or noncompliant packages. A ProGet login is not required.

If there are Noncomplaint packages or warnings, the developer can then comment on the PR why it's nothing to worry about. If it's always the same package/issue ("we cannot upgrade from this 5-year old library and replacing it would be a substantial effort"), then you can formalize that as an exemption.

The advantage to this workflow is that, if a deployed build later becomes noncomplaint (typically due to a vulnerability), then you can decide how and when to address it. The wrong time to address noncomplaint packages is "the next time a developer happens to open this project".

Overall, what you want to avoid is having developers load a project for what should be a trivial change and then have to upgrade dependencies because it produces pointless warnings/errors. That will just create a "constant upgrade" mentality. That leads to constant regressions and constant headaches for testers or end-users, who have to deal with strange and unexpected errors from library upgrades.

Hope that helps,

Alana

Hi @rcpa0,

It's hard to say, but maybe it has something to do with how the package file / archive was created.

Can you share the file or a reproduction case?

Thanks,
Alana

Hi @brandon_owensby_2976 ,

Thanks for clarifying; it got a little distracting with the desire to have PR cleanups and specialized variables! We also see a lot of anti-patterns in Git repositories, such as using PRs for workflows, because that's how open source projects tend to work.

Anyway, it sounds like you figured it the first part, which is to set the monitor to just create a build with a specific pipeline (e.g. "Feature Branch" pipeline).

The next step, just use a retention policy that targets builds that have completed the pipeline. For example:

https://docs.inedo.com/docs/buildmaster/builds-continuous-integration/buildmaster-ci-git-workflows/buildmaster-git-feature-branches#cleaning-up-feature-branch-builds-with-retention-rules

Hi @brandon_owensby_2976 ,

Here is the standard practice / pattern that we support for Feature Branches:

The idea is that developers start by creating a well-named feature branch (i.e. following a strict naming standard), adding commits to it, testing it, and then finally submitting a pull request for it. See our Feature Branches article to learn more about this workflow, including how retention rules can be configured.

In other words, the Pull Request comes only once the branch is ready (validated) for merging, and BuildMaster is submitting (or facilitating) that request. We take the term literally ("a request to pull the changes from the branch into into the master"):

• The branch owner is responsible for creating a "mergeable branch" and submitting that for review; a KPI here is is submitting timely/acceptable requests
• The master owner is responsible for promptly reviewing the request, then merging, closing, and deleting the branch; a KPI here is timely review/merging

In this workflow, there is no need for "commit verification" before submitting a PR. That's the responsibility of the branch owner, and they will have already done that before submitting.

I am aware that others do not use Git repositories this way, but our tooling is a generally opinionated. For example, we consider "pull requests as a backlog" as an anti-pattern for several reasons, but mostly that it's an inappropriate tool for work item management and lacks any semblance of prioritization and related feature. Issue tracking is appropriate for backlog tracking. So thaht's why there's not first-class support for it in BuildMaster.

All this said, I don't think the "Feature Branch" workflow is what you're describing. I don't quite understand it, but long story short... if it doesn't really fit into one of our use cases, so it's isn't something that's going to be easy to configure in the software - and you'll likely need to start customizing with your own Extension.

Instead, we recommend to just adjust the workflow.

Thanks,
Alana

Hi @Nils-Nilsson ,

We'll implement something like Scenario B, which mirrors how the UI handles it and is the easiest to implement:

pgutil feeds create --name=myfeed --type=NuGet --group=mygroup

We'll also target this for July 24th's release, and ship via PG-3338.

Thanks,
Alana

Hi @Nils-Nilsson,

Sorry on the slow response; we finally got the chance now to prioritize some roadmap items.

In any case, this will be implemented as PG-3337 in an upcoming maintenance release (targeting July 24).

Thanks,
Alana

Hi @pmsensi ,

Oh sorry I didn't realize or notice it when reviewing the reply. We decided not to include it after all, mostly because we couldn't realistically model/generalize the data across ecosystems when it comes to things like how NPM handles dev-level dependencies, how PyPI handles environment dependencies, etc. The UI display garners a decent number of "complaints" because it doesn't represent it the same way as say, npmjs.org for example.

That said, the manifest file (i.e. .nuspec) is cached in the database, but there's no "ProGet" API to retrieve that.

You'd have to use the NuGet-specific API for that, or just download the package file and then extract the .nuspec file.

Thanks,
Alana

Hi @pmsensi,

I don't believe that was ever in the PackageMetadata object; that information is stored in ecosystem-specific formats inside of the manifest file (e.g. .nuspec) in the package and it's not something we can easily generalize. The UI shows a "simplified" version but it's not always correct or suitable for metadata/api results.

You'd have to parse those metadata files to get that information.

hope that helps,

Alana

Hi @paul.moors_5682 ,

Without more details it's hard to say; this may be normal/expected depending on the feed type.

The numbers displayed in the UI show what information is in the database, not what's on disk. So it's possible to have files on disk that aren't in the database, and vice versa.

The Feed Integrity scan (part of ProGet 2025+) will help identify database entries without files. Then, you can run a "feed reindex" you can chose to delete database entries for missing files.

Hope that helps,
Alana

Hi @andreas.unverdorben_1551 ,

Just as an FYI, I submitted two pull requests for this:

• https://github.com/github/advisory-database/pull/8689
• https://github.com/github/advisory-database/pull/8690

Thanks,
Alana

Hi @jeff-miles_5073 ,

You can get information about images and tags using the Docker API; we do not provide documentation on how to use that (see our caveat on Feed Endpoints). And unfortunately the Docker API is a bit awkward, but with enough ChatGPT you should be able to figure it out :)

You could also query the database directly, perhaps building some kind of data export tool so that you can sync it with your dashboard.

Hope that helps,
Alana

Hi @mhelp_5176 ,

Provided you provided appropriate permissions, there shouldn't be an issue configuring the service to run as a gSMA.

Thanks,
Alana

Hi @mhelp_5176,

Not at this time; this would add complexity to the software and installation, so we're hesitant to give an option to configure this path without a compelling technical benefit.

Given your requirements, perhaps they should just configure the %ProgramData% folder to be on a different drive? Many Windows programs use that location for data like this.

Or perhaps configure a junction (soft link).

Thanks,
Alana

Hi @Nils-Nilsson ,

It's possible but it's quite complex; there are dozens of variable/macros that rely on context (some will give an error) and none of them have built-in dummy data. That would make templating expressions like <% if %> or <% foreach %> difficult to test.

In theory, you could enter a large box of variable expressions (like $FeedName=fake-feed)... but at that point, it's just easier to test things by performing the actions on a real package. A quick pgutil packages delete + pgutil packages upload script works great for that... that's how we test.

Thanks,
Alana

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!