400 Bad Request When Uploading builds with Powershell

RT · 26 April 2018 21:36

I’m trying to use powershell to upload our builds to octopus deploy. but when I do I get an error:

"The Remote server returned an error: (400) Bad Request. From the other discussions that people have started, it sounds like that error is supposed to indicate that the build being uploaded is the same name as another already uploaded. However this is not the case. I only have one build uploaded which was uploaded through the web interface. and but it has a unique name and version number.

I’ve tried several attempts using powershell to upload builds, but with no luck.
Here’s some examples:

1. Your Octopus URL

$octopusUrl = “http://deploy.localhost.org”;

2. An API key, preferably for a Service Account (Octopus Deploy documentation | Documentation and Support)

$apiKey = “API-Key”

3. Path to the package file to upload

$packageFilePath = “\AppMyShareoctopusdev\ArtifactDeposits\faClientScratch.1.0.25.zip”;

4. true to overwrite existing packages (Requires: BuiltInFeedAdminister permission)

$replaceExisting = $true;

$packageUrl = $octopusUrl + “/api/packages/raw?replace=” + $replaceExisting;

Write-Host Uploading $packageFilePath to $packageUrl;

$webRequest = [System.Net.HttpWebRequest]::Create($packageUrl);
$webRequest.AllowWriteStreamBuffering = $false
$webRequest.SendChunked = $true
$webRequest.Accept = “application/json”;
$webRequest.ContentType = “application/json”;
$webRequest.Method = “POST”;
$webRequest.Headers[“X-Octopus-ApiKey”] = $apiKey;

$packageFileStream = new-object IO.FileStream $packageFilePath,‘Open’,‘Read’,‘Read’
$boundary = "----------------------------" + [System.DateTime]::Now.Ticks.ToString("x");
$boundarybytes = [System.Text.Encoding]::ASCII.GetBytes("`r`n--" + $boundary + "`r`n")
$webRequest.ContentType = "multipart/form-data; boundary=" + $boundary;
$webRequest.GetRequestStream().Write($boundarybytes, 0, $boundarybytes.Length);

$header = "Content-Disposition: form-data; filename="""+ [System.IO.Path]::GetFileName($packageFilePath) +"""`r`nContent-Type: application/octet-stream`r`n`r`n";
$headerbytes = [System.Text.Encoding]::ASCII.GetBytes($header);
$webRequest.GetRequestStream().Write($headerbytes, 0, $headerbytes.Length);
$packageFileStream.CopyTo($webRequest.GetRequestStream());
$webRequest.GetRequestStream().Write($boundarybytes, 0, $boundarybytes.Length);
$webRequest.GetRequestStream().Flush();
$webRequest.GetRequestStream().Close();

$packageFileStream.Close();
$packageFileStream.Dispose();
$webResponse = $webRequest.GetResponse();
Write-Host $webResponse.StatusCode $webResponse.StatusDescription;
$webResponse.Dispose();

Another Script I tried was to use the following script by itself as well as in a powershell foreach loop:

Blockquote
$wc = new-object System.Net.WebClient
$wc.UploadFile(“http://localhost/api/packages/raw?apiKey=API-key”, “faClientScratch.1.0.25.zip”>)

Any help would be greatly appreciated. I did look for this topic before posting but was unable to find a matching issue. The APIkey being used is tied to an account that has admin access in octopus deploy, if that helps.

benpearce · 27 April 2018 00:58

Hi Ryan,

Thanks for getting in touch.

The script you have pasted in to the issue seems to have some formatting issues, but that may be a result of pasting it to the forum.
I took a copy of the Powershell code from the sample on GitHub and it worked when pushing a package to my local Octopus instance. I also used an API key from an admin user.
Changing the replaceExisting to false also resulted in a 409 response code.

To test that you don’t have a different problem that the Powershell code is hiding, can you try pushing the package using the Octo.exe command and see if that gives you a different results.
You can also use Nuget.exe to push packages to Octopus.

Regards
Ben

RT · 27 April 2018 13:47

I don’t have octo.exe and I don’t have nugget.exe, So I would really like to get the powershell script to work. That Sample that you reference is the script I’m using, and uploaded. The API key I’m using is that of an admin user.

Ryan D. Taylor

Devops

my529

Direct: 801.869.8933 | uesp.org

Toll Free: 800.418.2551 | Fax: 801.321.7299

my529_Logo_email sig

P
Please consider the environment before printing this e-mail.

This communication, including any attachments, is confidential and intended only for the addressee. No one other than the named addressee is authorized to read or retain this communication. If you have received this communication in error, please contact us immediately.

Because the confidentiality of Internet e-mail cannot be guaranteed, do not include private or confidential information such as passwords, account numbers, social security numbers, etc., in e-mails to us.

The Utah Educational Savings Plan (UESP) cannot provide legal, financial, or tax advice and this communication and any attachments do not contain legal, financial, or tax advice and cannot be construed as such or relied upon for those purposes.

RT · 27 April 2018 13:50

In my searching before I ran across an article where someone ran into something like this due to a tls conflict. They specified tls12 In their script and it resolved their issue. I can’t find the article again, So I don’t know how to do that, but I do know that we do have some tls restrictions. So if it’s trying to use tls 1.0 it will fail, I wonder if that’s the issue. But I don’t know the syntax to tell the script to use a different version of tls or ssl.

Ryan D. Taylor

Devops

my529

Direct: 801.869.8933 | uesp.org

Toll Free: 800.418.2551 | Fax: 801.321.7299

my529_Logo_email sig

P
Please consider the environment before printing this e-mail.

This communication, including any attachments, is confidential and intended only for the addressee. No one other than the named addressee is authorized to read or retain this communication. If you have received this communication in error, please contact us immediately.

Because the confidentiality of Internet e-mail cannot be guaranteed, do not include private or confidential information such as passwords, account numbers, social security numbers, etc., in e-mails to us.

The Utah Educational Savings Plan (UESP) cannot provide legal, financial, or tax advice and this communication and any attachments do not contain legal, financial, or tax advice and cannot be construed as such or relied upon for those purposes.

RT · 27 April 2018 14:56

Ben I found the tls syntax information (See below) but it didn’t help I’m still getting a (400) Bad request when trying to use the sample from github.

Not all build servers are going to be running windows. Some build servers will be running linux. Hence my desire to use powershell since it can run on both. Any help would be appreciated.

[Net.ServicePointManager]::SecurityProtocol =

[Net.SecurityProtocolType]::Tls12

Ryan D. Taylor

Devops

my529

Direct: 801.869.8933 | uesp.org

Toll Free: 800.418.2551 | Fax: 801.321.7299

my529_Logo_email sig

P
Please consider the environment before printing this e-mail.

This communication, including any attachments, is confidential and intended only for the addressee. No one other than the named addressee is authorized to read or retain this communication. If you have received this communication in error, please contact us immediately.

Because the confidentiality of Internet e-mail cannot be guaranteed, do not include private or confidential information such as passwords, account numbers, social security numbers, etc., in e-mails to us.

The Utah Educational Savings Plan (UESP) cannot provide legal, financial, or tax advice and this communication and any attachments do not contain legal, financial, or tax advice and cannot be construed as such or relied upon for those purposes.

RT · 27 April 2018 17:18

Ok I feel dumb now. I didn’t realize that octo had a download for redhat as well. I’ll do as you suggested and try octo to see what I get.

RT · 27 April 2018 18:22

I used octo.exe via the following command found from here:
https://octopus.com/docs/api-and-integration/octo.exe-command-line/pushing-packages using an api key of a member of the administrators group and of course replacing the package names. I get a http 401 unauthorized exit code -7. Please help I don’t understand why I seem to keep getting errors that don’t apply.

C:> Octo.exe push --package MyPackage.1.0.0.zip --package MyOtherPackage.1.0.1.nupkg --server http://my.octopus.url --apiKey API-XXXXXXXXXXXXXXXX

benpearce · 30 April 2018 00:56

Hi Ryan,

The URLs you have provided each time do not have HTTPS on them, so it is unlikely that this is a TLS issue.
The 401 error you are receiving suggests that API you are using either belongs to a user who doesn’t have a Push Package permission or doesn’t match any valid API key.
The next things I would suggest are turning on debug output within Octo.exe using the --debug parameter, and also creating a new API key against the Admin user account, or another user who has the Push Package permission.

Regards
Ben

RT · 30 April 2018 16:02

I’ll turn on the debug and send it. The scripts im sending are your own scripts That I’m sending over for reference so you know how I’m trying to do what I’m doing. I’m not going to send them over with my actual urls (which are https) or with my api key for security reasons. The only user I have is a administrator user in octopus deploy. That’s whats making this so strange, is the fact that it the API is tied to an admin user. I don’t even have any non admin users, so the error that it’s giving. To rule out the api key, I’ve even made a new api key for the admin user and copied and pasted it into my script. So the api key is valid and since it’s tied to the admin account has full permisions.

benpearce · 2 May 2018 01:30

Hi Ryan,

I have verified that the PowerShell scripts you have provided are correct and working against my local Octopus instance. So this leaves the API key, TLS and network as potential problems.

We can try to rule out the network and TLS by calling http://your.octopusserver/api. This endpoint does not require authentication and you should receive back a JSON document containing some server information and a link collection for all the resources exposed by the Octopus server. You can do this in a browser (incognito or private mode to avoid any currently logged in sessions) or use Postman or write a PowerShell script.
If this call is causing issues then the TLS configuration or some other network condition could be the cause. For TLS there is some troubleshooting steps in relation to TLS.
To test if your local network is causing any issues, you could try running the Octo.exe command or previously mentioned PowerShell scripts directly on the Octopus Server. We have previously seen issues where a firewall, proxy or other network appliance might modify the traffic, such as HTTP headers, and cause the request to fail.
You can specify the API key on the request URL as a parameter too, ?apikey=APIKEY. If there are network conditions in the way this may also be a workaround.

I hope one of these suggestions helps you resolve your issue.

Regards
Ben

system · 8 June 2018 21:46

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.