2017-09-08T16:05:54.3879126Z <h2>404 - File or directory not found.</h2>
2017-09-08T16:05:54.3879126Z <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3>
So I changed to map what I put in the URL. I changed it back (also fixed sending over packages I don't need)
Per your instructions, I switched it back and now it's working! Something obviously got out of sync and is now fixed.
That "register URL" box that Microsoft provides unfortunately doesn't allow us to warn users when they register incorrect URLs. Registering it with app#/ is a very common and understandable mistake.
I'm gonna submit a PR for our plugin to do some validations on that URL before we attempt to run the octo.exe command. Something that prints a warning if the URL ends in /app#/ or /api/ which are the 2 most common scenarios.
If it worked once with that same URL (which looks ok to me) and then it failed, then we have to start thinking about the network aspect.
You mentioned your build agent is on-prem. In that case what I would try to do is:
1) Remote into that build agent and download octo.exe to it (download link)
2) Open a web browser on the agent and try to access the Octopus server from http://s01vci02/. You should be able to see the Octopus web portal for this to work.
3) If (2) worked, try running the same Octo.exe command you see on the build log, but from a local powershell session in that build agent VM.
4) If you keep getting intermittent results, you might wanna check your Octopus Server logs and see if the portal is working intermittently. If that's the case, you should see plenty of messages saying the service started/stopped. In the Octopus Server VM the logs would be in C:\Octopus\Logs by default.
2) When I did that - there was a noticeable delay before the page loaded - so it seems we do have an issue on the network
This is most likely the root cause of the issue.
Running after that update - it succeeded. The build server is also under heavy load - I'm wondering if that may be a factor.
All the build server does is send a POST call to the Octopus server, which starts the deployment and sends the order to the Tentacles. So the build server is not exactly doing a heavy-load work really. In this case I would investigate (in this order):
Resource usage on the Octopus Server VM while the process is running.
Resource usage on the Tentacles while process is running.
Network connection between Build agent <-> Octopus Server.
Network connection between Tentacle <-> Octopus Server
I too have a strange problem with Octo.exe push.
1. I have a 118MB zip file (created by octopack)
2. From the command line on a windows VM, I execute octo.exe push
3. It succeeds (every time).
4. My colleague, logs onto the same VM and runs the exact same command (same API key, same file path, same url) and he gets the same error that has been reported here (every time he runs it):
Unexpected character encountered while parsing value: <. Path '', line 0, position 0..
5. Curiously, if the file is split into two smaller files, my colleague can successfully upload both files.
6. The failure occurs within a couple of seconds (so it doesn’t seem to be timeout related).
7. This behaviour occurs in the latest octo.exe (and in the previous version we were using).
Thanks for reaching out. The error Unexpected character encountered while parsing value: < usually means that the code was expecting a JSON blob as a result, but instead got an HTML page (which starts with the character <). This often means that the request returned an error in the form of an HTML page.
There's nothing in the Octopus code that would limit package push depending on the user and size of the package. So I'm thinking this could be some sort of network.
What I recommend you to do is:
1) Run the Octo.exe command with the flag --debug to see if you get extra logging that might help with the troubleshooting.
2) Setup Fiddler to monitor the network calls being made by that command. Sometimes Fiddler returns a bit more logging to help in these situations.
3) Can your teammate try to push the package from another machine (lets say his workstation) and see if he gets the same result?
Thanks for your response.
The --debug option didn't give us much unfortunately, and before we could test with fiddler, another colleague of mine, (much smarter than I am!) suggested looking at the Proxy settings (under Local Area Network (LAN) Settings - From IE go to Tools/Internet Options/Connections/Lan settings).
And sure enough we discovered that ticking the "Bypass proxy server for local addresses" resolved our issue.
I guess our proxy were was being used to route local traffic and it didn't like the large file size.
We're having a similar issue pushing a zip file from VSTS to an Octopus instance of ours and we're getting a HTTP 404 error. How can we disable proxying from a VSTS build controller? We only seem to have this issue for one project that's using .zip files.
Just to double check: When you say VSTS build controller you mean one hosted by Microsoft and not by your company, correct?
Could you share me a build log so I can see what you are using to push the package (octo.exe,nuget.exe,etc) along with the rest of the build context? This conversation is public so I recommend you to send it to our email instead.
Hi Dal! We figured out the issue. It was our IIS ARR configuration. By default, there's a requestlimit in bytes value set to 30,000 bytes (approx. 30MB). I changed the value to 2GB and that solved our problem. /doh
Previously we only used AWS ELB and Route53, but moving to IIS ARR we forgot about this default setting. Most of our teams were deploying packages that were under this 30MB limit up until someone had to go over that limit. Lesson learned.