I just noticed this in the ProGet Jenkins plugin docs:

dependencies (optional)

An array of strings, each consisting of a package identification string; this string is formatted as follows:

�group�:�package-name�

�group�:�package-name�:�version�

When the version is not specified, the latest is used.

Type: String

This is for the upload parameters. I don't remember seeing this before, is this new, and/or related to my consumes pattern?

Just wanted to come back to say this worked; I did it during work hours and there weren't any downtime issues. (I made sure to communicate that there might be some, no one complained.)

I did have to revert the config change after my first attempt, because it couldn't find any files. I think I did the manual drag-n-drop of the Packages folder to the new location incorrectly - creating Packages/Packages/. On my second run I used RoboCopy and it worked great.

I also had to set the permissions on the new folder location to include the NETWORK SERVICE user, which ProGet is running as, with full access. Maybe I should have used the robocopy command that copies perms as well, but it all seems to be working now.

And also to clarify again:
all except the most recent 3 versions matching mybranch from the feed

means:
in this feed, delete matches of 'mybranch', except the latest 3 versions of those matches, which would only impact the versions matching mybranch and leave all other non-matches untouched;

and not:
in this feed, delete everything except the latest three versions of 'mybranch', which would leave ONLY the latest three versions of mybranch, and delete eveything else, which would obviously be a major problem.

Is that correct? I mean, it has to be, but I just want to be sure.

This means mybranch and mybranch2 can be reduced to mybranch2.

Sorry but wouldn't this be the reverse: *mybranch* will match *mybranch2*?

It seems to work normally now with the homepage setting to none. The default category is support. So I'm happy! Thanks!

Thanks Alana!

Would my Drop Path idea work for this, and reduce the manual steps?

Also - if we change the path without changing anything else, will proget just start keeping new packages in the new path, and still be able to access the old path?

Here's another example. If I have two rules:

1. all except the most recent 3 versions matching *mybranch* from the feed
2. all except the most recent 3 versions matching *mybranch2* from the feed

This is achieved by creating two rules, each set up with 'delete all except the latest 3 versions' and 'delete packages with matching versions' with *mybranch* and *mybranch2*

Which will the behavior be?

1. It will remove everything except the last 3 versions of both mybranch and mybranch2, OR
2. it will not remove anything except the last 3 versions of both mybranch and mybranch2

I want the behavior of #2. My plan is upon publishing from Jenkins, it will also set up a rule, if it does not exist already, for the branch name it is pushing to only keep 3 versions of that branch. I don't want any given rule to affect packages with any other branch names other than what is in that rule. So if I have a rule to delete branch1, I don't ever want it to delete anything from branch2.

After reading over this 18942 times, I believe the mechanism requires all criteria of each rule to pass before executing the delete - so i think the behavior will be what I want, that of #2 above, and only packages with versions matching mybranch or mybranch2 will be deleted (except the most recent 3 of each).

Please confirm! Thanks!

---

To avoid this kind of uncertainty, maybe the UI text for each rule could be clarified to something like, "Package versions matching *mybranch2*, except the most recent 3 of that package, will be deleted". I think i am reading all except the most recent 3 versions matching mybranch from the feed to mean, "everything else will be deleted except the most recent 3 versions matching mybranch". Which I don't think is right, but it's just not clear enough to be sure.

Thanks!!

My apologies if this isn't covered elsewhere, i searched pretty deeply in the docs and this forum and haven't found anything.

We originally set up ProGet to keep its packages in C:\ProgramData\ProGet\Packages\..., but we want to move the data storage to the D: drive, as that's a better practice, and it also has 1TB space on it vs 100GB on C:, which we have hit a few times.

What is the least friction way to do this? This doc says,

When you change a feed's disk directory... the package files will not be moved.

One thing I can think of is to move the storage root path to D:/something, and then set up a Drop Path of the existing location. Would that result in all of the packages being copied correctly into the new location? Would any metadata be lost? Is there a better way?

Thanks!

Changed it to "none" and it's back to normal. But if i select a specific category (i've only tried Support tbh) it fails with the same error as before.

I don't remember seeing this before. Clearly something's off.

It's empty; it says "select category".

FWIW, i also see this unrelated bug at the home page:

I always forget to set the topic to "support" when creating a new forum thread. Is there a way to set it to default to this setting?

Hi! We are trying to set up a coherent retention policy for our development feeds. We are currently using a process that designed with a lot of input from Inedo, so i hope you might have some insight on this detail of managing it.

For a given repo/package, we push all ci builds from Jenkins to a <feedname>_dev feed. Only packages that are cleared for production deploy are repackaged into a <feedname> feed, which is considered the production feed.

So we end up with a ton of branch builds littering the _dev feeds, most of which are never needed. I've been unable to come up with a generic retention policy for the dev feeds that prunes the unneeded builds, but always leaves at least one build from each branch available, until it can fade out after say 30 days.

What I am considering is adding a step in the publish process to use the Retention API to create a new retention policy for every new branch published to ProGet. That way we can set up a specific policy for each new branch.

The problem is obviously that we will have to clean up the retention policies at some point.

An example might help:

• package 1
  • versions
    1. branch1-v1
    2. branch1-v2
    3. branch2-v1
    4. branch2-v2

If I want to keep only the latest 5 versions, it will not guarantee that branch2 will keep its latest version available if branch1 keeps publishing builds.

Without the api approach, I can't see a way to mitigate this using the existing tools available: deleting/keeping versions or names that match/don't match a wildcard string. Maybe I am just not seeing it!

Thanks in advance!

Also relates to https://forums.inedo.com/post/12249

Hi, thanks - yep, it appears that plugin is assuming that field is not null. Good find!

There aren't any errors from proget either in the output of the plugin upload in the jenkins console, or in the proget error logs, as far as i can tell.

Plugin issue: https://issues.jenkins.io/browse/JENKINS-67923

Thanks again for all your great help!

Hi, i like having the option of organizing packages in a feed with GroupNames (I'd still like the UI to organize them better, see this post)

But what if i don't want a groupname? i just want feedname/packages?

At least when using the jenkins plugin, this doesn't seem to be an option. I either have to give "null" as a group, which isn't the answer, or if it's just not present, like feedname/packagename, the plugin upload succeeds but the packages is nowhere to be found. The resultant upload URL gives a 404.

That makes sense. Is there any way to import files into an Asset Dir from a URL - so I don't have to download the file and import it to ProGet manually?

Hi, thanks. I'm not sure I've done it correctly, but it doesn't appear to be working.

I have the connector pointing at https://services.gradle.org/distributions/ and am using the connector in a new feed, public-gradle.

If I search for "gradle" it finds no matches.

I'm also getting a certificate error when running gradle, but i don't know if that's coming from my connection to proget or proget's connection to gradle.org.

Downloading https://proget.mycompany.com/maven2/public-gradle/gradle-7.3-bin.zip

Exception in thread "main" javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Hi, i'm reopening this thread as the public docker connector has been available for a while now, but I can't figure out how to use it.

I have the connector set up to point at https://registry.hub.docker.com
The setting Do not attempt to search the container registry was automatically enabled.

I have a feed public-docker set up to use the connector. The connector shows Active and Healthy, although it shows no known package count (I believe this is expected).

Overall, I'm not sure how to use it. The documentation reads as self-conflicting, although I don't know enough about it to say that for sure. That's why I'm asking.

From https://docs.inedo.com/docs/proget-docker-connectors:

You can also create a connector to an external (non-ProGet) registry such as Docker Hub. This could be useful to whitelist certain base images, or to cache them on your local infrastructure.

but then...

Many external registries such as Docker Hub do not expose an API for searching and discovery of images, so the ProGet web UI cannot be used to search or browse for images stored in one of these registries via connector.

So, i see that I can't search in the UI for images. That's alright, but how can i make sure my docker pull or docker run commands go through the ProGet feed, so the images can be cached, instead of directly out to the Docker Hub?

Thanks!

I have connectors set up for Chocolatey, nuget, and Docker public feeds (docker isn't working). I would like to set up a connector to services.gradle.org so i can point my gradle builds' distributionUrl at a proget feed instead of the external feed. I don't see a gradle type in the connector setup pane, is there a way to do this?
Thanks!

It is pretty easy; I just wanted to know. Thanks for the reply!