upack repack doesn't use complete version string from CLI

MaxCascone

Hi, I'm playing around with upack, and seeing some confusing behavior.

If i repack a package with version 1.0.11-develop-2041 to 1.0.11-develop-2043-repack, the new upack filename does not represent that version, nor the original version:

> ls | select name
myApp-1.0.11-develop-2041.upack

> upack repack .\myApp-1.0.11-develop-2041.upack --newVersion='1.0.11-develop-2043-repack' --note='repackaged from old version'
Package: myGroup/myApp
Version: 1.0.11-develop-2043-repack

> ls | select name
myApp-1.0.11-develop-2041.upack
myApp-1.0.11.upack    <-- shouldn't this be '1.0.11-develop-2043-repack'?

The new version is correctly shown in the upack.json:

{
  "group": "myGroup",
  "name": "myApp",
  "version": "1.0.11-develop-2043-repack",
  "description": "myApp",
  "_git_commit": "<a hash>",
  "_built_by": "Jenkins",
  "_build_link": "<a jenkins url>",
  "repackageHistory": [
    {
      "id": "myGroup/myApp:1.0.11-develop-2041:<a hash>",
      "date": "2022-10-11 21:23:51Z",
      "using": "upack/2.2.6",
      "by": "mcascone1",
      "reason": "repackaged from old version"
    }
  ]
}

Am I doing something wrong, or is this an issue with upack? Would you rather I submit this as a upack github repo issue?

> upack version
upack 2.2.6.1

One more thing! I can't push or pull with upack:

> upack install myGroup/myApp 1.0.13-POLLY-Test-75 --source=https://proget.myOrg.com/upack/Platdev_dev --user=mcascone1@myOrg.com:<redacted pw>
The underlying connection was closed: An unexpected error occurred on a send.

stevedennis

Hi @mcascone ,

Just looking at the code real quick, I suspect we have a bug where it writes out the wrong files name for the new package:
https://github.com/Inedo/upack/blob/master/src/upack/Repack.cs#L120

That's probably an easy fix, which we can do as part of this Q&A item. I'll wait to hear back about this one.

As for the error, "The underlying connection was closed: An unexpected error occurred on a send.", that sounds like it's HTTPS related. Could you attach Fiddler, or something like that, to find out what's happening under the hood? We may be able to error message to better report it if so.

Cheers,
Steve

MaxCascone

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)

stevedennis

Hi @mcascone,

I'm not sure if we'll be able to help too much with analyzing your Wireshark traffic to be honest; we're not really experts at debugging TCP/SSL-level things, and we'd probably need to spend a half a day re-learning how it all works before we could tell you what it might even be.

There's likely some obscure Windows setting or some network setting that your network ops team would be much more familiar with. They're a lot more familiar than we are :)

As for the upack bug, I just posted an issue now -- https://github.com/Inedo/upack/issues/72

We don't have a regular release schedule for upack, so I can't give an ETA.... hopefully it's relatively easy to work-around for the timebeing?

Cheers,
Steve

MaxCascone

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.)

MaxCascone

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

matt.janda.kingston_9734

@mcascone Hi Max, can't believe we meet here... I had hopes for upack but will end up with old Invoke-WebRequest :(

MaxCascone

@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!