Whoops, I accidentally forked the topic, so I'm just going to quote it in here instead @smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed: @atripp Hello. I have got the same behaviour too. With fiddler i see that all versions i unlisted before have property <d:Listed m:type="Edm.Boolean">false</d:Listed> , but still apeear in VisualStudio, nuget list and even Rider. Version - 5.3.0 (Build 126-5.3.0). I think this one is related: https://forums.inedo.com/topic/2675/owner-has-unlisted-the-package-on-nuget-org-but-proget-still-shows-it-in-the-list-of-availible-versions/4 @smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed: @atripp Hello. I have got the same behaviour too. With fiddler i see that all versions i unlisted before have property <d:Listed m:type="Edm.Boolean">false</d:Listed> , but still apeear in VisualStudio, nuget list and even Rider. Version - 5.3.0 (Build 126-5.3.0). I think this one is related: https://forums.inedo.com/topic/2675/owner-has-unlisted-the-package-on-nuget-org-but-proget-still-shows-it-in-the-list-of-availible-versions/4 @smolkov-anton_1636 said in Unlisted NuGet Packages showing as listed in feed: The same is for new nuget V3 API. Steps to reproduce: Unlist all versions of package in proget UI List only one version / push new version Expected result: Visual Studio UI shows only one version which was listed Observed result: Visual Studio UI shows all the versions

Not in particular; .NET does garbage collection, in the background, as needed; so it's not uncommon to see processes "swell" to consume available memory and then "contract" overtime, as memory usage (percentage-wise) gets high.

Ok. Thanks. I will hunt it down.

@atripp said in Still cannot push Windows Docker image to ProGet: install an intermediate tool, like Fiddler or Wireshark, to capture traffic from your workstation. Maybe the raw traffic will give you a better clue. Hey. No errors that seem relevant in the Diagnostic Center. I'll try to set up Fiddler and see if I can go from there.

Thanks for the update.

Hello; That's a good question; we can't reproduce this, if the file is instantaneous through the browser, we can be totally assured that the problem isn't ProGet finding and sending that .deb file over the web. apt install isn't any more complicated than that. Can you put a sort of Proxy Server or traffic monitor between the two? Maybe it's network related? Maybe at a TCP/SSL packet level? Maybe apt has a sort of throttle? I guess you could also try to curl the file from whatever server you're doing apt install on to further track it down? hope thsi helps track it down, please share what you find in case anyone else experiences it. Alana

In my opinion, using $ApplicationName is not possible, at least for Gitlab Indeed from GitLab ref, we read : The URL a badge points to, as well as the image URL, can contain placeholders which will be evaluated when displaying the badge. The following placeholders are available: * %{project_path}: Path of a project including the parent groups * %{project_id}: Database ID associated with a project * %{default_branch}: Default branch name configured for a project’s repository * %{commit_sha}: ID of the most recent commit to the default branch of a project’s repository As %{project_path} is different from $ApplicationName if the project is defined in a group, the only link between the gitlab project and the builmaster application is the commit_sha var. I think you just need to add stage as querystring and make the search for the result of the pipeline named stage for which exists an active build variable ($commitId in my example) with a value of commit_sha. and $commitId has to be unique over all BuidMaster. Actually, it is not possible to get more variables (ideally %{project_path} at the GitLab::Get-source step. The filter would be then better (Filter for project_path+ commitid + stage), but this is still a build variable and not an implicit variable like $ApplicationName I don't know if there a better way because I have just started to use Gitlab.

Hello; it's the first request for this, but we're going to investigate adding this to ProGet as PG-1702. We'll update as we make progress on investigation.

Hmm, for this, then it seems -Repository is the argument?

For this case, you're right -- the Instance ID would be the way to go. On the new BuildMaster server, you can set the Agent.InstanceId field (any string is fine, "bm62" would work) , so this way, both BuildMaster instances won't collide. We are using our "Customer Success Program" to provide upgrade assistance for BuildMaster 6.2, so the best way to get started on this would be to talk to your account representative. You can also submit a ticket and put 6.2 UPGRADE in the "How can we help" section, and we'll route that to the right people :)

I noticed that the latest Proget version has a v3 connector for nuget so I added that and also re-indexed the package store, recomputed the checksums and deleted invalid packages. While running the re-indexing I encountered three errors that indicated bad packages (files in use), so I deleted all three packages, ran the re-indexing and everything appears to be working again. I suspect the problem was the bad packages in the store. Thank you @atripp for your help in this matter.

Hello; That "error" message is to be expected; that's what ProGet returns when you visit to /v2 with a web browser. But the error sounds like a sort of SSL/certificate configuration problem. After searching for "tls: no renegotiation", here is an article I found about that might help: https://www.digicert.com/news/2011-06-03-ssl-renego/

@atripp Thanks

@atripp Hello You are right I have seen just after the post when rc = 1 shexec exit with an error. I have to handle the rc inside the script. So I remove the post because it was not necessayr anymore Thanks for the reply

Thanks for the update! I've noted this in the docs, and linked to this discussion :) https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Gitlab offers too many options/features we don't need (CI/CD, Kubernetes, Promotheus etc ....). This is why I was looking for a more lightweight Git repo I was previously using BonoboGit on Windows which a very basic Git repo but good enough for our need. As the webhook is not possible, I am looking to replace it. I think we will stay on GitLab CE - everything is working and I can't spend my time to evaluate all the possible software, I have to pick one and use it.

Hello; Sounds like there's a lot to unpack... First, we've got some major changes in ProGet 5.3 that should help out quite a bit, but I've included a lot of resources in this post to consider as well. Consider that, as a private registry, ProGet is designed to host "private images" that you manage (which can be build from "public images"), and it's really not designed as a "registry mirror/cache". These are two different usecases. The authentication issues, that might be different problem and might be worth a new thread? Repository Mirroring in ProGet From But here is our current thoughts/documentation on repository mirroring in Proget: There is the ability to "mirror" hub.docker.org, but this feature was really only designed to enable Docker, Inc. to host public registries in sensitive regions like China (so you can mirror to registry.docker-cn.com instead). Unfortunately, the Docker client will only use the configured "mirror" for building and pulling; images are always pushed to hub.docker.org. Docker, Inc. does not seem to be interested in enabling this, and we aren't particularly keen on forking the Docker client to enable this. Thus, it seems there's no sense in ProGet supporting this anytime soon Base Image Pattern On Dockerhub, there are a lot of problematic images that cause a new breed of "worked on my Docker" problems in companies. openjdk:11 is a great example of this problem. The connector "problems" in ProGet are a symptom of the problem, but we strongly recommend you to not use "third-party" container image directly, but instead follow our "base image" development pattern. First, and foremost, openjdk:11 currently references what's called a "fat" manifest, which is a sort of "pointer" to other manifests that will be used depending on the run-time environment of Docker. There are currently four different environment-specific images that this "fat" manifest points to, so when you build an image on top of it (e.g. FROM openjdk:11), your image will be "locked" to whatever environment configuration the build machine (or even workstation) had at the time the command was run. This may be different than the machine you run the image on. Even more problematic, however, is that 11 is a time-sensitive tag, and what 11 refers to keeps changing. Today, it points to four different versions of four different images (as of 7 days ago), but tomorrow... it could point to 3 totally different images. Who knows? It's a repository maintained by a third party, and 11 means what they say it means, at their discretion. The Dockerhub is meant to be the "authority" on this repository, and this is where connectors are a challenge. ProGet caches certain informations about these images, but when the meaning of these things change, it defeats the purpose of caching. If you disable caching, it should work... but then you've already , but what's the point then? You're downloading huge image files constantly then. So instead, here's how we recommend you develop a practice around third-party base images. docker pull openjdk:11 docker tag openjdk:11 proget.mycompany.com/dev-images/openjdk-linux64:11.0.6-rc.1 docker push proget.mycompany.com/devimages/mycomp/openjdk-linux64:11.0.6-rc.1 Even better would be to use a Dockerfile (e.g. FROM openjdk:11) that lets you customize the image as needed, but this a good start. Then, after you/developers are happy with that version of that image, then you can "re-tag" from 11.0.6-rc.1 to 11.0.6. In ProGet 5.3, these operations are made easier, and "virtual" tags are automatically generated. But the important thing is that you treat "tags" as immutable, and provide consistent images for your users. Note that, the repository name is mycomp/openjdk-linux64. It's important to not use only openjdk-linux64, since that name is identical to _/openjdk-linux64 and library/openjdk-linux64. The library/empty/_ namespace are intended only for "Dockerhub-certified" images Docker is supposed to solve "works on my machine", but unless you treat tags as immutable, you'll keep getting "works on my Docker when I ran it," and that's even harder to debug. ProGet is "exposing" the underlying problems with these machine-specific, time-specific tags, but I guess it's better to discover it early on, then in Production.