Hi @MaxCascone ,

Thanks for pointing these out; we will get the RPM icon fixed (probably a minor CSS thing), and then then hide the option on the Manage Asset Directory page (via PG-2540).

This view is intended mostly for ProGet ISV Edition use cases, and we likely won't expand on this in ProGet 2024, since you're probably first person who commented on it

Cheers,
Dean

Hi @kigiwow570_6179,

I don't have enough information/specifics to answer the questions; it really depends on the API queries being made, etc. Some API calls result in errors, others do not. In general, doing a NuGet restore will not result in errors being logged.

Best,
Dean

Hi @kigiwow570_6179 ,

These errors are being "forwarded" from NuGet.org, and if you're seeing them it means that "something" on your network is making requests to a ProGet feed that has a connector to nuget.org.

This is typically an old, outdated tool or script. You'll need to track this down and update/disable it.

It could also be a self-connector that is connecting to a feed that also has a connector to ProGet using the V2 APi - so double check your self-connectors.

Best,
Dean

Hi @philippe-camelio_3885 ,

You mention the server is crashing? That's really strange, and we've never quite seen anything like this before. We routinely test on much less powerful hardware in nearly identical scenarios that you are doing now.

SQL Server / .NET will use as much ram as it can, so the usage isn't surprising or really concerning.

Otherwise we don't really any info info on the errors --- You'll need to track down error messages from the ProGet side of things; perhaps the Docker container error logs, the SQL Server error logs, etc. Maybe try putting the npm client (i.e. BuildMaster) on a different server, just to help isolate any potential issues.

We've seen a lot of weird things happen -- every now and then, there's a problem with the network controller/hardware/driver on the server, and it's having a hard time processing the 1000's of simultaneous "loopback" connections that npm is making from the BuildMaster container to the ProGet container, and the "outbound" connections that npm would be making to npmjs.org.

But until you find out what those errors are on the ProGet side, it's impossible to guess.

Thanks @philippe-camelio_3885 , roger that!

I thought you were reffering to the API :)

We'll get this fixed as BM-3912 in a future maintenance release, likely Dec 14 since it's a holiday week coming up here in the states.

Cheers,
Dean

Hi @philippe-camelio_3885 ,

Thanks for clarifying; so it sounds like you're talking about Variable Prompts (Templates), which are part of a pipeline?

These are not "variables" per se; instead, they are used to prompt users at certain points during a pipeline (creating build, deploying build, etc.) to input values. Those values will then be created as variables.

We don't plan to extend templates outside of pipelines. If you reaaaaly wanted to, you could create a BuildMaster "application that creates applications" using the API and then leverages the pipeline prompts to create the variables in the format you want.

It's probably just easier to clone an application, however.

Cheers,
Dean

Hi @philippe-camelio_3885 ,

I'm sorry it's not really clear what you're trying to accomplish.... you can define list-based variables at all levels. Just specify the value like @(a,b,c), for example.

Cheers,
Dean

Hi @philippe-camelio_3885 ,

Sorry - it's not really clear what the issue is; can you share more details? Ideally a way I can reproduce this in a new instance of BuildMaster, but also maybe a screenshot or the APi calls you're making?

Thanks,
Dean

Hi @pallavi-tarigonda_9617,

These errors are being "forwarded" from NuGet.org, and if you're seeing them it means that "something" on your network is making requests to a ProGet feed that has a connector to nuget.org.

This is typically an old, outdated tool or script. You'll need to track this down and update/disable it.

It could also be a self-connector that is connecting to a feed that also has a connector to ProGet using the V2 APi - so double check your self-connectors.

Best,
Dean

@Srinidhi-Patwari_0272 here is the api for healthcheck:
https://docs.inedo.com/docs/proget-reference-api-health

the url would be /health

Hi @Srinidhi-Patwari_0272 ... it sounds like everything's working on the ProGet side, but I'm not familiar enough with troubleshooting Terraform/etc. to advise how to troubleshoot automating that.

Hi @Srinidhi-Patwari_0272,

The domain name is abcd.efg.com and the port is 8624; it's very likely someone will need to open that port on the firewall as well.

Cheers,
Dean

Hi @v-makkenze_6348 ,

This is the first time I've seen a "link": true type entry in a lock file.

The docs for package-lock.json aren't very clear for what this signifies, aside from:

A flag to indicate that this is a symbolic link. If this is present, no other fields are specified, since the link target will also be included in the lockfile.

Not sure how a "link" entry like that gets added to a lock file, but I think we should just skip it then? Basically add code in that loop that does this?

if (npmDependencyPackage.Value.TryGetProperty("link", out var link) && link.GetBoolean() == true)
  continue;

What do you think?

Cheers,
Dean

@Srinidhi-Patwari_0272 said in How to automate ProGet installation via ansible so that ProGet and SQL EXPRESS gets added to D drive instead of default C drive:

How to make ProGet URL accessible to all?

If you're able to access ProGet while being logged into the server, then it means the web server is up and running without issues.

From here, you'll need to adjust Windows firewall settings and/or enable DNS so that others can access. There's also certificate settings you'll need possibly. I'd check w/ your network team on this --- definitely not a change you can make inside of ProGet itself.

Hi @Evan_Mulawski_8840 ,

That particular bug may be resolved by running the patch script attached to this upcoming change: https://inedo.myjetbrains.com/youtrack/issue/PG-2484

As for retrying the migration; there will be a button on the ProGet root page if there is a failed/incomplete migration (/) that allows you to retry it. This will open to the /retry-migration URL, which I would recommend using instead of a database insert.

Best,
Dean

Hi @hashim-abu-gellban_3562,

Due to some reasons I don't fully understand, authenticating to the Docker API requires using a Bearer authentication token Authorization: Bearer {token}

Here is an example for how to get that token:

function GetDockerToken() {

    param (
        [string] $packageName = $(throw "-packageName is required.  This is the namespace and image name.  For example: library/my-container-image"),
        [string] $feed = $(throw "-feed is required"),
        [string] $actionToAuthorize = $(throw "-action is required.  This is the docker action to be authorized (pull, push, delete, etc)"),
        [string] $apiKey = $(throw "-apiKey is required"),
        [string] $progetBaseUrl = $(throw "-progetBaseUrl is required. "),
	[string] $service
    )


	if ($service -eq "") {
          # This expects that $progetBaseUrl is prepended with "https://"  If you are using "http://" then change 8 to 7 below.
	  $service = $progetBaseUrl.SubString(8,$progetBaseUrl.Length-8)
	}

	$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f "api","$apiKey")))
	$response = Invoke-WebRequest -Uri "$progetBaseUrl/v2/_auth?service=$service&scope=repository`:$feed/$packageName`:$actionToAuthorize" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}
	if ($response.StatusDescription -eq "OK") {
		$token = ($response.Content | ConvertFrom-Json).token
		$token
	}
}

I know we plan to document all this better some day, for now you can find the Semantic Versioning for Containers page.

Dean

Hi @Stephen-Schaff,

Thanks for the detailed write-up; the behavior you describe makes sense, and made for very copy/pasting PG-2478 :)

We anticipate getting this in the next maintenance release, scheduled for Sept 15

Best,
Dean

Hi @hashim-abu-gellban_3562,

DockerImages_GetTags is part of the Native API, which is basically just a wrapper around the SQL ProGet database. That's fine to use, but you can also use the Docker API to list tags as follows:

curl -X GET https://proget-url/v2/feedName/repositoryName/tags/list

The Docker API will show you tags that come through a connector, where as the Native API is will only be local tags.

The Docker API does not provide a way to directly retrieve the operating system information of Docker images. However, you can infer the operating system information by examining the contents of the Docker image itself or by using external tools and scripts.

Here's an example in Python of how to do that:

import docker

def get_os_of_image(image_name, tag):
    client = docker.from_env()
    image = client.images.get(f"{image_name}:{tag}")
    os_info = image.attrs['Os']
    return os_info

# Example usage
os_info = get_os_of_image('my-image', 'latest')
print(f"Operating System: {os_info}")

Alternatively, you can also inspect the image layers directly. Docker image layers contain files from the image's filesystem, and you can look for specific files or patterns that are indicative of the operating system.

Best,
Dean

Hi @pariv_0352,

What version of ProGet are you using?

Perhaps this is related to this:
https://forums.inedo.com/topic/3596/proget-2022-6-the-hostname-could-not-be-parsed

Dean

@jw that's the correct column! Just the incorrect value being added :(