Build pipeline fails at task 'push packages to Octopus'
##[section]Starting: Push Packages to Octopus
Task : Push Package(s) to Octopus
Description : Push your NuGet or Zip package to your Octopus Deploy Server
Version : 4.0.387
Author : Octopus Deploy
Help : Version: 4.0.387. More Information
65978706-f70e-4ac0-8dc7-7f61db0ce4d8 exists true
Attempting to contact https://g.octopushq.com to find Octo command line tool version latest
Checking local tool cache
Found tool in cache: Octo 6.13.1 x64
Looking for E:\vsts\a_tool\Octo\6.13.1\x64*Octo.dll
Prepending PATH environment variable with directory: E:\vsts\a_tool\Octo\6.13.1\x64
[command]C:\Windows\system32\cmd.exe /D /S /C "E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd version"
E:\vsts\a\5833\s>dotnet "E:\vsts\a_tool\Octo\6.13.1\x64/Octo.dll" version
6.13.1
[command]C:\Windows\system32\cmd.exe /D /S /C "E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd push "--server=https://octopus.bentley.com/" "--apiKey=***" "--space=Spaces-1" "--package=E:/vsts/a/5833/a/PGDQApp.2019.9.16.2.nupkg" "--overwrite-mode=OverwriteExisting""
E:\vsts\a\5833\s>dotnet "E:\vsts\a_tool\Octo\6.13.1\x64/Octo.dll" push "--server=https://octopus.bentley.com/" "--apiKey=***" "--space=Spaces-1" "--package=E:/vsts/a/5833/a/PGDQApp.2019.9.16.2.nupkg" "--overwrite-mode=OverwriteExisting"
Octopus Deploy Command Line Tool, version 6.13.1
Detected automation environment: "AzureDevOps"
Found space: Default (Spaces-1)
Space name specified, process is now running in the context of space: Default
Handshaking with Octopus Server: https://octopus.bentley.com/
Handshake successful. Octopus version: 2019.7.13; API version: 3.0.0
Authenticated as: Neha Lahoti
Pushing package: E:\vsts\a\5833\a\PGDQApp.2019.9.16.2.nupkg...
Requesting signature for delta compression from the server for upload of a package with id 'PGDQApp' and version '2019.9.16.2'
No package with the same ID exists on the server
Falling back to pushing the complete package to the server
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: BuiltInFeedPush
Exit code: -5
[error]Error: The process 'E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd' failed with exit code 4294967291
[error]Failed to push package. The process 'E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd' failed with exit code 4294967291
[section]Finishing: Push Packages to Octopus
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: BuiltInFeedPush Exit code: -5
Seems like you are missing permissions to push a package?
Keep in mind that in Octopus you need to have permissions to all the projects that are using that package in order to push a new version of it (as pushing a package might trigger a new deployment on specific projects)
Related
I'm currently developing a Blazor WebAssembly application that will be deployed on an Azure Static Web App through a BitBucket pipeline.
pipelines:
branches:
main:
- step:
name: Deploy to test
deployment: test
script:
- pipe: microsoft/azure-static-web-apps-deploy:main
variables:
APP_LOCATION: "$BITBUCKET_CLONE_DIR/PriorityCasesClient/PriorityCasesClient"
OUTPUT_LOCATION: "$BITBUCKET_CLONE_DIR/PriorityCasesClient/PriorityCasesClient/wwwroot"
API_TOKEN: $deployment_token
I however keep running into below error when Oryx is trying to build the solution.
It seems that the pipeline points to the correct locations and the solution is found and correctly restored, as can be seen below, but when Roslyn kicks in it hits me with the following:
error MSB6004: The specified task executable location "/ (deleted)" is invalid
Successfully installed workload(s) wasm-tools.
Determining projects to restore...
Restored /opt/atlassian/pipelines/agent/build/PriorityCasesClient/PriorityCasesClient/PriorityCasesClient.csproj (in 1.84 sec).
Publishing to directory /bin/staticsites/ss-oryx/app...
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
/opt/dotnet/6.0.301/sdk/6.0.301/Roslyn/Microsoft.CSharp.Core.targets(75,5): error MSB6004: The specified task executable location "/ (deleted)" is invalid. [/opt/atlassian/pipelines/agent/build/PriorityCasesClient/PriorityCasesClient/PriorityCasesClient.csproj]
---End of Oryx build logs---
Oryx has failed to build the solution.
Can anyone possible see something wrong with my pipeline, or point me in a direction?
I am trying to restore NuGet packages from the Azure Artifacts feed with the task "Nuget restore" which is giving an error -
2020-03-17T06:16:01.923910Z Resolved from tool cache: 4.1.0
2020-03-17T06:16:01.939365Z Using version: 4.1.0
2020-03-17T06:16:01.924520Z Found tool in cache: NuGet 4.1.0 x64
2020-03-17T06:16:02.080668Z [command]C:\Windows\system32\chcp.com 65001
2020-03-17T06:16:02.007116Z Active code page: 65001
2020-03-17T06:16:02.012223Z Detected NuGet version 4.1.0.2450 / 4.1.0
2020-03-17T06:16:02.081611Z SYSTEMVSSCONNECTION exists true
2020-03-17T06:16:04.157611Z ##[error]Error: Error: read ECONNRESET
2020-03-17T06:16:04.190260Z ##[error]Packages failed to restore
Details -
Server - Azure DevOps server 2019
Azure DevOps build pipeline
Azure Artifacts Feed - offline
Agent Version 2.144.2
What I noticed
my "Nuget Restore" task is working well when my build machine is in the same LAN with azure DevOps server and giving an error with the different LAN's build machine.
I googled but did not find anything. some pages showing this error is because of the proxy, some page is showing version issue of NuGet.
Not getting what exactly the issue is. Can someone help with this?
Sonarqube error in VSTS Build when version 4 of sonar extension is used.
Error -
[SQ] API GET. '/api/server/version' failed, error was:
{"code":"UNABLE_TO_GET_ISSUER_CERT_LOCALLY"} .
SonarQube extension version 3 build runs successfully.
We are using Sonarqube version 7.1
I also faced same error:
[error][SQ] API GET '/api/server/version' failed, error was: {"code":"UNABLE_TO_GET_ISSUER_CERT_LOCALLY"
To fix this issue:
First I installed Java 17 to devOps build agent machine https://www.oracle.com/java/technologies/javase/jdk17-archive-downloads.html
Java SE Development Kit 17.0.5 Windows x64 Installer.
Installed path: C:\Program Files\Java\jdk-17.0.5
Then add two devOps build pipeline variables:
NODE_EXTRA_CA_CERTS and SONAR_SCANNER_OPTS
SONAR_SCANNER_OPTS:
Copy your cacerts and replace existing one.
path: “…\Java\jdk 17.0.5\lib\security\cacerts”
Then add both paths in devOps SONAR_SCANNER_OPTS variable:
-Djavax.net.ssl.trustStore="C:\program files\Java\jdk 17.0.5\lib\security\cacerts"
-Djavax.net.ssl.keyStore="C:\program files\Java\jdk 17.0.5\lib\security\cacerts"
NODE_EXTRA_CA_CERTS:
copy your cert *.PEM file and replace it the existing one in devops build agent path: C:\devOps_Agent\sonarchain.pem
After this step SonarQube prepare starting to work.
Current discussion thread:
http://devnet.jetbrains.com/message/5519081#5519081
Bug Report: http://youtrack.jetbrains.com/issue/TW-37148
Error: Cannot prompt for input in non-interactive mode.
One thing to note is that the credentials prompt is triggering on each package download instead of at the beginning. I think this may be a bug in the way Team City is calling NuGet, but I'm not sure.
I have the "NuGet Feed Credentials" build feature configured, basic auth configured, and I've run the feed in Firefox and got the list of packages to show up on the agent machine (with credentials required).
My build log: https://gist.github.com/tonyeung/517597ca2312dad85f62
The following is a workaround which may help you, although I was of the impression the NuGet Feed Credentials build feature was meant to fix the problem. I was having a similar issue with the internal TeamCity NuGet feed without guest access (called Local in this example).
Initial build step (command line - custom script)
del /F %env.APPDATA%\NuGet\NuGet.Config
%teamcity.agent.tools.dir%\NuGet.CommandLine.DEFAULT.nupkg\tools\nuget.exe sources add -name Local -source %env.NuGetFeed%
%teamcity.agent.tools.dir%\NuGet.CommandLine.DEFAULT.nupkg\tools\nuget.exe sources update -Name Local -User %env.BuildServiceUser% -pass %env.BuildServicePassword%
As I say, it's a workaround, but not too much to maintain if using templates. Hopefully it gets you up and running.
I know this is an old question, but I recently came across this issue in TeamCity 9.1.7.
In my case, the issue was that I had a trailing slash on the Server URL, found in Administration > Global Settings. Removing that slash made the authentication work correctly.
For the TeamCity 8.1.2 (build 29993), I solved this issue by installing the Nuget v. 2.8.0 at the TeamCity Administration panel (I had v.2.8.2). Then I've added "Nuget Install" build step and set up the NuGet Feed Credentials build feature.
Probably, if you'll update the TeamCity it would also fix this issue.
To solve
http://localhost:80/httpAuth/app/nuget/v1/FeedService.svc: The V2 feed at 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/Packages(Id='***',Version='1.0.0')' returned an unexpected status code '401 Unauthorized'.
issue I have done:
create local administrator account
net user tcbagent password123 /add
net localgroup administrators tcbagent /add
attach "Logon as service" permissions (using Carbon PS helpers)
Grant-CAPrivilege -Identity tcbagent "SeServiceLogonRight"
create account within TeamCity
run cmd using destination environment
runas /user:tcbagent cmd
add nuget source with credentials
nuget sources add -name local -source http://localhost/httpAuth/app/nuget/v1/FeedService.svc -UserName tcbagent -Password password123
localhost of whatever you need
check your teamcity-build.log file to get something like this:
Starting NuGet.exe 3.5.0.1284 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT\tools\NuGet.exe
...
Restoring NuGet package xxxx.
...
Using credentials from config. UserName: tcbagent
TeamCity v9.1.7, NuGet v3.5.0-beta
I've spend 2 days to resolve it because I'm quite new with TeamCity and CI.
Hope it was helpful.
seem like a similar issue to https://nuget.codeplex.com/workitem/4172.
Can you try the workaround at the bottom of the issue description?
I'm using Jenkins on Win7 and i've installed tomcat for ssh-agent plugin. And I could clone my GitLab project via git bash via ssh.
But if I build the project by Jenkins, it always says :
[ssh-agent] Using credentials IliptonChen(APRTest)
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider
FATAL:[ssh-agent] Unable to start agent
The full output text is here
Did I do anything wrong?
Check the version of your ssh-agent used by Jenkins.
This bug (for linux, but could apply to Windows too) reports (10 days ago, January 2014) this very same error message:
"JENKINS-20276: Native Library Error after upgrading ssh-agent from 1.3 to 1.4".
Downgrading to 1.3 resolves the issue.
Update 2019, five years later: as commented, this should be fixed now.
ssh-agent.exe is part of a Git for Windows distribution
D:\git\git>where ssh-agent.exe
D:\prgs\gits\current\usr\bin\ssh-agent.exe
(provided path/to/git/usr/bin is first in the %PATH% used by Jenkins)
Assuming you've installed Windows Git on Windows slave, it comes with ssh-agent binary (e.g. C:\Program Files\Git\usr\bin). Try adding its path to system variable PATH.
Otherwise untick SSH Agent and choose the credentials by selecting Credentials from dropdown in Source Code Management section.
Another way is to generate personal API token (OAuth) for that GitHub user and include that along with your repository address, e.g.
git clone https://4UTHT0KEN#github.com/foo/bar
For windows, the plugin still requires Tomcat to be installed in both master and slave.
I got this error because I was using an Ubuntu image for the agent, which doesn't have SSH installed.
agent {
docker { image 'ubuntu:focal' }
}
... so the solution was as simple as installing SSH as part of the pipeline:
steps {
sh "apt-get update && apt-get install ssh -y"
// rest of your steps here...
}
In my case, the error was accompanied by an error about disk space depletion:
[ssh-agent] FATAL: Could not find a suitable ssh-agent provider
[ssh-agent] Diagnostic report
[ssh-agent] * Exec ssh-agent (binary ssh-agent on a remote machine)
[ssh-agent] hudson.AbortException: Failed to run ssh-agent: mkdtemp: private socket dir: No space left on device
So I ran docker system prune -a, which fixed it.