Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Hi @itadmin_9894 ,

It's not possible to edit vulnerability records, as they are updated/source from outside of your ProGet software.

You're also using an older version of ProGet that sources data from OSS Index. That database is generally unreliable and outdated, so if you're concerned about vulnerabilities you should definitely upgrade:
https://docs.inedo.com/docs/proget/installation/proget-old-versions-migration/proget-compliance-ossindex

It looks like the similar/equivalent is here:
https://security.inedo.com/vulnerability/details/PGV-245118T

Cheers,
Alana

Hi @e-rotteveel_1850,

Glad to hear it!

Our only exposure to the Conda ecosystem is writing a feed for it, so hope you don't mind a few "dumb" questions :)

Are there any official/public packages (from like the anaconda repository) that have this field? I presume those would also be in their index.

Any idea where these might be officially documented? I found a reference in the meta.yaml specs, but you said "json" and that's clearly "yaml". I figure maybe it turns into a json at some point.

Are there any similar fields? I see we parse a bunch of fields, like constrains to dev_url.

Cheers,
Alana

@lisama7982_5385 this would require using the Docker API, which is kind off a pain, but if you search for things like "how to tag an image with a digest usng Docker API" or something you should find it eventually

You can also use the Docker CLI by doing something like docker pull using the digest, then docker tag, then docker push.

If this is a one-time clean-up you may also wish to query the database tables, like Docker* tables will allow you to eventually find what images you need to tag. Just don't delete from the database, since that can cause a headache and it won't delete files from disk

Hope that helps :)

Hi @jimbobmcgee,

Good question on versioning... to be honest I kind of forgot how assembly binding would work in this particular context

The Otter.Core assembly version changes in each release. I don't think we have special handling for it, but you could probably add in an assembly resolver for now, until we officially add support. The Job Template / Variables is something we have on our 2025 roadmap for Otter, but other products are priority.

Security... BuildMaster handles it a little better, and will do runtime checks, and does allow for more flexibility. This serverlock we added in Otter was a stopgap in 2022 (I think?) to resolve a customer's issue. The issue you are encountering is relatively easy to work-around, by reimplementing server targeting using variables. It's also on our roadmap, but you know... priorities :)

Hi @lisama7982_5385,

This is something that Retention Rules are typically used for, but as a home/hobby user I understand how that doesn't make sense.

You cannot navigate to these images in the ProGEt UI, which means you can't delete them from the UI. So I would just tag them, then you can browse and delete them.

Cheers,
Alana

Hi @monika-sadlok_5031 ,

I hate copy/pasting what I wrote earlier, but I feel that I've already answered these questions.

The only way this error is possible if there is no network connection between the application container and the SqlServer Container. There are no other scenarios in which this error will occur.

If it's always happening, then it's likely due to your container's network configuration (often it's a typo, like inedosql and inedo-sql or something in your configuration)

Please ignore "BuildMaster"...

, that's just a stack trace showing us where the error occurred, and specifically the code file name/line number. Those paths refer to the build server (i.e. BuildMaster) that ProGet was compiled on.

Ultimately there is something wrong with your Docker configuration. Docker is not esy to troubleshoot/maintain, so I would consider moving to Windows if you are new/uncomfortable troubleshooting.

Cheers,
Alana

@jimbobmcgee thanks again for the detailed analysis & debugging, definitely not easy doing so "blind" like that :)

Anyway we will investigate/patch via OT-516 - I haven't looked but what you're describing sounds like a reasonable conclusion, i.e. the incoming agent isn't getting matched up.

@jimbobmcgee thank you again for the very detailed analysis; we will get this fixed via OT-515, it's most an easy encoding to add

Hi @jimbobmcgee,

This restriction is for security purposes, specifically to enable the usecase of Otter enabling end-users to create/edit/run scripts, but not decide where they are run. So the for server is locked unless the targeting is set to None.

The solution is to indeed add a variable that allows you to select a server... but as you noticed, you'd have to type in a list. We simply ran out of time to bring those over from BuildMaster unfortunately, and this is not really a popular Otter requirement.

But sure it's possible, it's called a VariableTemplateType. Here is the code from BuildMaster that you could probably copy/paste into a custom extension.

But the issue is that you don't have access to DB in the SDK. Kind of a pain, but you could either reference Otter.Core.dll in your Nuget Package, use reflection, call DB directrly, etc.

[Category("Infrastructure")]
[DisplayName("Servers")]
[Description("Servers configured in BuildMaster, optionally filtered by one or more environments")]
public sealed class ServerListVariableSource : BuildMasterDynamicListVariableType
{
    [Persistent]
    [DisplayName("Environment filter")]
    [PlaceholderText("Any environment")]
    [Inedo.Web.SuggestableValue(typeof(EnvironmentNameSuggestionProvider))]
    public string EnvironmentsFilter { get; set; }

    private class EnvironmentNameSuggestionProvider : ISuggestionProvider
    {
        public async Task<IEnumerable<string>> GetSuggestionsAsync(IComponentConfiguration config) =>
            (await DB
                .Environments_GetEnvironmentsAsync().ConfigureAwait(false))
                .Select(e => e.Environment_Name);
    }

    public async override Task<IEnumerable<string>> EnumerateListValuesAsync(VariableTemplateContext context)
    {
        var values = (await DB.Environments_GetEnvironmentsAndServersAsync(false).ConfigureAwait(false))
            .EnvironmentServers_Extended
            .Where(es => es.Server_Active_Indicator)
            .Where(es => string.IsNullOrEmpty(this.EnvironmentsFilter) || string.Equals(this.EnvironmentsFilter, es.Environment_Name, StringComparison.OrdinalIgnoreCase))
            .Select(es => es.Server_Name)
            .Distinct();

        return values;
    }

    public override RichDescription GetDescription()
    {
        if (this.EnvironmentsFilter?.Length > 0)
            return new RichDescription("Servers in ", new ListHilite(this.EnvironmentsFilter), " environments.");
        else
            return new RichDescription("Servers in all environments.");
    }
}

It is on our list to "Make Job Template Varible Editor Closer to Pipeline Variable Editor", it's just not trivial and not a huge priority on our products roadmap (https://inedo.com/products/roadmap)

Cheers,
Alana

Hi @serveradmin_0226 ,

This is a network-related error and basically means that your ProGet container cannot talk to the SqlServer container. There are no other causes of this error.

If this error is sporadic, then it's likely related to the SqlContainer restarting or some other problem with the networking stack on the server. You'd need to investigate the timing of these errors with other things happening on the host server.

If it's always happening, then it's likely due to your container's network configuration (often it's a typo, like inedosql and inedo-sql or something in your configuration) or the SqlServer container could just not be running.

As for the logs, that's just a stack trace showing us where the error occurred, and specifically the code file name/line number. Those paths refer to the build server (i.e. BuildMaster) that ProGet was compiled on.