I think I can get close enough, without a lot of complexity, by using the retention rules, and setting them fairly tight since it's a dev feed and these packages are meant to be transient.

We don't have a package promotion process right now, although it's on my roadmap. These rules may have to be revisited when i implement that.

Right now I've got it set for:

• Delete unused versions not requested in last 30 days.

We are not great at deleting old branches, so this might actually be better than a branch-delete trigger. And if someone comes along and needs an old branch build, they can just rebuild it.

We don't really use the connector feature for our own feeds (or any), so i think this will do it.

I got a little confused at the combination of "keep only last 5 versions" plus the 30-day window. From what i've read in the docs, all conditions must pass for the item to be deleted. How do i set up, "keep only the last 5 versions, but when nothing has been requested for 30 days, delete them all"?

This solution has the benefit of simplicity and native functionality. I don't have to write a hacky, multi-tool process to manage it.

@stevedennis thank you very much for the quick reply!

I agree that there’s a smell to some of the process I’ve set up.

The gist of the problem I’ve tried to solve is: how can I guarantee that a deploy of a given branch will always get its latest build (unless a specific version is provided) from the development feed, if there are multiple feature branches in development at the same time, pushing to the same feed?

What I do now is tack the branch name onto the package name that I push up. That smells bad, but it guarantees that a branch deploy will always pull its own latest package.

The context here is a shared Jenkins pipeline that performs build, tag, publish to proget, and deploy, with specifics depending on the branch. I’ll be happy to do a deep dive, I’m sure there’s a ton of stuff I’ve done wrong.

I’ve lost the thread here a bit. To get back to the topic, I agree using retention policy is the best way to do what I’m after, with one question: how can I remove all versions of a package once it’s no longer needed, with that defined by the branch being deleted? I know that’s not an option in the retention policies, but what might have a similar effect?

Thanks
max

Hi, i want to delete all versions of a package via the API. So far I have this, which makes one API call per version. Is there a way to delete all versions of a package in one shot?

# get all versions of a package name from the API
$endpointBase = 'https://proget.myCompany.com/upack/myFeed'

$epEnd = 'packages?'

$branch = 'myBranch'

$results = Invoke-WebRequest -Method GET -Uri "$endpointBase/$epEnd" | 
  ConvertFrom-Json -AsHashtable | 
    Select-Object Group, Name, Versions | 
      Where-Object { $_.Name -match $branch }

# iterate through and delete one by one
foreach ($package in $results) {
  $pkgName = $package.Name
  $group   = $package.Group

  foreach ($version in $package.Versions) {
    $pkgVers = $version
    $deleteUri = "$endpointBase/delete/$group/$pkgName/$pkgVers"

    # /upack/«feed-name»/delete/«group-name»/«package-name»/«package-version»
    try {
      Invoke-RestMethod -Method DELETE -Uri $deleteUri -Headers @{"X-ApiKey" = "redacted"}
      Write-Output "Deleted $group/$pkgName/$pkgVers"
    }
    catch {
      Write-Output "Error: $pkgName/$pkgVers`: $_"
    }
  }
}

I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted, through a webhook from GH. I'm not exactly sure how that last part's going to work. If i'm going down a wrong path here, please let me know!

Found another one: On the proget dashboard, the Documentation link when hovering over the "user" icon is broken.

Link is http://inedo.com/support/documentation/proget?utm_source=proget&utm_medium=product&utm_campaign=proget5

New documentation! cool! But some links are broken.

https://docs.inedo.com/docs/upack-feed-api-endpoints gives a 404.

Add my plus-1 to sorting or searching or filtering by groupname in the UI.

As best I can remember, groupname is required by the upload process; at least, i remember it being required by the Jenkins plugin. Maybe i'm wrong/misremembering. But it does make sense for our use case to be able to divide feednames by groups. So it'd be great to have that functionality in the UI.

Thanks for the reply, that's pretty much what i figured, but it's always worth asking.

What i built at least as a first effort is: add an optional consumes parameter to the pipeline/Jenkinsfile, specifying the packages(s) to pull from ProGet as feedname:groupname:packagename:

• Jenkinsfile:

library 'my-shared-library'

sharedPipeline {
// ...
  consumes = 'myFeed:myGroup:myPackage'
// ...
}

• In the file that manages restoring prior to jenkins builds:

// if this repo consumes another package(s) from ProGet, get it here.
// The required syntax of 'consumes' is: 'proget_feedName:groupName:packageName'
// comma separate multiple packages
  if(env.consumes) {
    // create a [list] to support multiple packages
    env.consumes.split(/\s*,\s*/).each {
      downloadFromProget(it)
    }
  }

• downloadFromProget.groovy:

// common defaults
// Note that downloadProgetPackage seems to require a literal path - hence the {WORKSPACE}
  dlFolder  = "${WORKSPACE}/${env.packageDownloadDir}"
  ver = 'Latest'

//... a bunch of other custom patterns to download specific stuff ...

// packages to consume from ProGet need to come in as feedName:groupName:packageName
// check that it matches that syntax with regex (.+ means 1 or more of any char)
    else if (app ==~ /.+:.+:.+/)
      pkgMap  = app.split(':')
      fdName  = pkgMap[0]
      gpName  = pkgMap[1]
      pkgName = pkgMap[2]
      expFolder = "${WORKSPACE}/${pkgName}"
    }

// then download

downloadProgetPackage downloadFolder: dlFolder, 
    downloadFormat: 'zip',
    feedName:       fdName,
    groupName:      gpName,
    packageName:    pkgName,
    version:        ver

The last thing i've yet to do is change all my package pulling to use the unpack mode of downloading from proget, so i can remove the unzipping steps on my side.

We are in the process of adopting ProGet as our one-stop-shop for internal package management. We are using it as a build artifact store, and we pull from it to do deploys. Now, i am onboarding an app that consumes another app's build as part of its build. The consumee is already published as a Universal Package to ProGet.

I'm wondering if there's a way to add this package as-is to the consumer's packages.config file, so that it gets pulled down by a nuget restore? This would avoid having to build a separate step that pulls the package to consume.

As a ProGet user in the web UI,
I would like to be able to filter the Feeds list by Group,
so i can narrow down my searches more effectively.

The person building this seemed to be having some luck with the Assets, he needed to use the api endpoint exposed in the download link area. I'll follow up when i get more info.

We're looking into using ProGet as a publish target for our ClickOnce applications. Is there an established pattern for doing this? Where would they best be pointed - a true Feed, or an Asset Directory?

Hi, i'm running into this now in Version 5.3.17 (Build 19). All of our packages are internal use only and i don't want to bother with setting up license rules. Can i disable the license checking?

Hi, thanks for the reply. I checked that i can hit that url with a browser, so it's not blocked. InfoSec confirmed the whole domain is open through our ZScaler.

I did look in the config of the Hub and it was not set as you suggest. I changed it to the right url, and it doesn't fail, but it doesn't seem to find the update.

I can add one more thing, that one of the SQL services isn't running, and i had to restart another one. They were both in 'disabled' state. It doesn't change the behavior of the Hub, though.

PS C:\Users\MaxCadmin\Downloads> Get-Service *inedo*

Status   Name               DisplayName
------   ----               -----------
Running  INEDOPROGETSVC     ProGet Service
Running  MSSQL$INEDO        SQL Server (INEDO)
Stopped  SQLAgent$INEDO     SQL Server Agent (INEDO)
Stopped  SQLTELEMETRY$INEDO SQL Server CEIP service (INEDO)

Now, all but the SQLAgent are running, and i can't get it running - when i start, it gives the error

The SQL Server Agent (INEDO) service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.

PS C:\Users\MaxCadmin\Downloads> Get-Service *inedo*

Status   Name               DisplayName
------   ----               -----------
Running  INEDOPROGETSVC     ProGet Service
Running  MSSQL$INEDO        SQL Server (INEDO)
Stopped  SQLAgent$INEDO     SQL Server Agent (INEDO)
Running  SQLTELEMETRY$INEDO SQL Server CEIP service (INEDO)

Solution

There is an error in "View Error" that suggested my l couldn't access the Proget2 DB. I realized I have begun logging in to everything with a new Admin account, and it was probably confusing the issue as i set up Proget with my original user account.
I was able to open SQL Server Management Studio as the user account, and add my admin account to the Proget2 db.
I re-launched Hub, and behold, the Upgrade button was now there. It went quickly and smoothly, and now i am upgraded.

I need to upgrade my ProGet instance that seems to not have connectivity to part of the inedo hub download process, so i'm trying to do an offline upgrade. I created the offline installer for the 5.3.10 version and copied a .zip of the folder to the proget server.

(I actually did this with proget: i created the zip on my workstation and uploaded it to proget as an asset, and downloaded it on the actual proget VM.)

When i launch the InedoHub.exe from the offline installer folder, it actually shows an incorrect version of ProGet: 5.3.0-m.5, while my proget ui shows 5.3.7 (build 12); and doesn't give me the option to upgrade it. What am I doing wrong?

When i launch the inedo hub that is installed on the VM, it too shows the obsolete version, and says I can't do anything before upgrading the hub. It gets stuck and quits during this process.

I would much prefer to be able to just do a regular online upgrade. There's no policy that this machine can't have access to the internet, and it can hit most external sites, but it always gets stuck on the "downloading indedo hub" step of the update process. What URLs must i request to be whitelisted by IT to enable the regular online process to work?

Thanks!

Fantastic, looking forward to it! Sorry for the work, but i'm happy to contribute in some small way as well!

FWIW, i'm using the Versions API endpoint to get the list of versions, and you could build your own parsing from there. I'm sure this is mostly wrong, but this is what I'm doing, in Jenkins:

// get latest version of package on proget
// https://docs.inedo.com/docs/upack/feed-api/endpoints#list-versions
// compare to build's versionfile
def response = httpRequest ignoreSslErrors: true, 
               url: "${env.progetUrl}/${env.progetFeedType}/${env.feedName}/versions?group=${env.groupName}&name=${env.serviceName}", 
               wrapAsMultipart: false    

def content  = readJSON text: response.getContent()

// Versions are always returned as an array, even if count = 1
// So just always get the last element in the array.
env.latestVersion = content.version[-1]

echo "Latest published version is ${env.latestVersion}, date: ${content.published[-1]}"
echo "Jenkins is building version: ${env.tag}"

// compareResult returns:
// -1 if v1 < v2
// 0  if v1 == v2
// 1  if v1 > v2
compareResult = compareVersions v1: env.latestVersion, v2: env.tag

@rhessinger Thank you!!

@rhessinger Hi, I'm sorry i didn't see your reply come in sooner.

I am using a Universal Package feed.

I'm uploading with the Jenkins extension, which i believe just wraps the API, but I'm not sure.

It's a very simple call, it won't show much, but this is it:

  uploadProgetPackage artifacts:   env.artifact,
                      feedName:    env.feedName,
                      groupName:   env.groupName,
                      packageName: env.appName,
                      version:     env.tag 

thanks
max

Ok, i've got the latest version 5.3.7 on local and production, and i'm still seeing no change in the "published" date when i upload a package with an existing version number. However, in the Event Log, I do see several "Package Modified" events for that package, so it looks like the request is coming in and something is happening. Is it because I am testing this with the same exact upload package each time, so the hash is the same, so it's determining it's exactly the same package, so it doesn't update the metadata? If i change the package with a new/changed file, should it update the metadata? I'll update when i test.

UPDATE: I added a test file to the uploaded package without changing the version. My observation is that the new package is uploaded. However there's no indication that the overwrite happened. The Event Log is the only clue, that it was Updated.

I think what i would like to see is that history of the package in the package's history page, and a Last Updated date being added to the Metadata tab. And the full history of updates etc should be in the package's History tab.

But at least i think i've proven that updated packages with conflicting versions are uploaded - there's just very little evidence of the overwrite happening. If there's anything else I'm missing, please let me know.
thanks!

@rhessinger i'm getting back to testing this now. I'm still on 5.3.0 (build 126), and i believe the api user has all the perms it needs, and it's still not overwriting.
I tested the latest version locally, and it does overwrite. So something on my production server isn't right, or the older version acts differently.