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.

Thanks Alana, I continue to be impressed with your and Inedo's responses to these issues!

We are not on v2022 yet, we are on the latest v6 as of a few weeks ago, but now we have a real reason to do it!

Thanks again!
Max

Thanks for the insight into your process on this. It's interesting.
For our part, I put everything I can on Confluence. I probably like Confluence as much as I hate Sharepoint and OneNote. (At least with OneNote I can actually create a document successfully.)

Flow charts help a lot, which are super easy to create and maintain with the Draw.io integration into Confluence.

I like confluence for its deep-linking into Jira as well.

Yuck, sharepoint?

I hear you; SOPs tend to wither and gather dust as the processes evolve, though, in my experience. That's why, while we get some real-world use of the manual promotion and versioning processes, in the hope that repeatable, reliable patterns emerge that we can then automate, we want to remind people in-flight what the process is supposed to be, so they don't make mistakes.

thanks for the reply!

@matt-janda-kingston_9734 my old friend! I am just now seeing this. I hope you are well! Hit me up at my email in my profile if you see this!

Hi, I like the idea of Tile View, but it doesn't seem to work in my install. I am on Version 2023.22 (Build 6).

In an RPM feed, it shows tiles, but no icon, just text.

In an Asset feed, it has no effect - the Asset directory is always shown in List view.

Settings:

RPM Feed:

List view has an icon:

Asset dir:

It appears this has been implemented and released!
https://inedo.myjetbrains.com/youtrack/issue/PG-2530

@hwittenborn Thanks! I had to install binutils first, and then got what looks like a valid tree in both packages I had:

root@e6c7c176bb0d:/tmp# ar tf NessusAgent.deb 
debian-binary
control.tar.xz
data.tar.xz

root@e6c7c176bb0d:/tmp# ar tf NessusAgent-10.4.2-ubuntu1404_amd64.deb 
debian-binary
control.tar.gz
data.tar.gz

The former is a repackaged version of the latter; using @luke_1024's mechanism above.

FWIW, ar tf was not a valid command on MacOS (bash 5.2) with binutils installed, but works as expected on the Ubuntu container (above).

I too am having this problem right now, and I don't even know how to look into the package to see if @hwittenborn 's fix is possible.

The file in question is not a cargo rust artifact but pulled from a provider's website.

I know the package still installs successfully, so as a workaround, I plan to put the deb pkg in ProGet as a simple file to be downloaded to the target.

@atripp I'm sorry to revive this old thread but I am having this exact same problem. Old email is <<redacted>>, I no longer work there; new email <<redacted>>. I think two new accounts got created somehow due to my failing efforts. Please help?

On my MacBook Pro M1, I was trying to follow the ProGet Docker-Compose instructions, but the SQL container was continuously restarting.

I found the answer here: https://github.com/microsoft/mssql-docker/issues/668#issuecomment-1436802153

TL;DR: In the Docker Desktop app, enable "Use Rosetta..." in the "Features In Development" settings pane.

Voila', it works!

@stevedennis , is there perhaps a switch or param that can enable no-ssl-checking in the upack cli? Somethink like -k --insecure in curl?

Hi, I'm just using curl to workaround the connectivity issue.

It works fine locally but I found that one of our Jenkins agents is rather old and doesn't have curl on it. As a workaround to that, for the time being, I'm using the curl installed as part of git:

This is the Jenkins code:

def publishNewPackage(String path, String dest, String feed) {
  // can't use the plugin to upload since we already have a upack
  // so just push it as-is.
  // as mentioned elsewhere there's an issue with upack connectivity
  // (https://forums.inedo.com/topic/3626/upack-repack-doesn-t-use-complete-version-string-from-cli)
  // so just use curl for now.
  // specifically pointing to the git curl, it's not in all versions of windows
  echo "Publishing ${path} to ${dest}/${feed}"
  String curlCmd = ". 'C:/Program Files/Git/mingw64/bin/curl.exe'"
  retry(3) {
    withCredentials([usernameColonPassword(credentialsId: 'proget-creds', variable: 'userpass')]) {
      pwsh "${curlCmd} ${dest}/${feed} --user \$env:userpass --upload-file ${path} --silent"
    }
  }
}

(The retry is because proget sometimes fails on the first LDAP lookup, but always works on a retry. I think it's more of an issue with our internal AD setup than with Proget.)

I've got a wireshark capture of the conversation between my local and proget via upack. I can't seem to upload it here, which is probably for the best, can i email it to you?

Any ETA on the filename fix? (every engineer's favorite question)