I have the following piece code (extracted from larger script):
Write-Output "Syncing $directory"
Push-Location $directory
git pull origin $branch
$directoryName = [IO.Path]::GetFileName($directory)
git log -n 1 --pretty=format:"%H %cd %aN%n%B" --date=short > "..\$directoryName.lastcommit.txt"
Pop-Location
Which occasionally (~50% chance) produces an error when run in a Windows Azure WebJob:
[05/06/2014 22:20:43 > e5e3ee: INFO] Syncing D:\home\site\!roslyn-sources\DeclarationExpressions
[05/06/2014 22:20:45 > e5e3ee: ERR ] From https://git01.codeplex.com/roslyn
[05/06/2014 22:20:45 > e5e3ee: ERR ] * branch DeclarationExpressions -> FETCH_HEAD
[05/06/2014 22:20:45 > e5e3ee: INFO] Already up-to-date.
[05/06/2014 22:20:45 > e5e3ee: INFO] [ERROR] Window title cannot be longer than 1023 characters.
[05/06/2014 22:20:45 > e5e3ee: INFO] Returning exit code 1
[05/06/2014 22:20:45 > e5e3ee: SYS INFO] Status changed to Failed
[05/06/2014 22:20:45 > e5e3ee: SYS ERR ] Job failed due to exit code 1
I never get this error when running locally.
What might be the reason?
Maybe the exe you are running are changin the Window Title.
So, instead of call git directly in your powershell script run it with the cmdlet Start-Process
Related
On job failure (exit code > 0) Rundeck automatically add detailed status informations to the notification attachment:
Failed: NonZeroResultCode: Remote command failed with exit status 1
Execution failed: 3709 in project test_project_1: [Workflow result: , step failures: {1=Dispatch failed on 1 nodes: [host1: NonZeroResultCode: Remote command failed with exit status 1 + {dataContext=MultiDataContextImpl(map={ContextView(step:1, node:host1)=BaseDataContext{{exec={exitCode=0}}}, ContextView(node:host1)=BaseDataContext{{exec={exitCode=0}}}}, base=null)} ]}, Node failures: {host1=[NonZeroResultCode: Remote command failed with exit status 1 + {dataContext=MultiDataContextImpl(map={ContextView(step:1, node:host1)=BaseDataContext{{exec={exitCode=0}}}, ContextView(node:host1)=BaseDataContext{{exec={exitCode=0}}}}, base=null)} ]}, status: failed]
Can this message by disabled / hiden to only send the script output like in attachment on a success job run?
You can force the "exit 0" in your step wrapping it on some inline script like this
#!/bin/bash
touch /root/test 2> /dev/null
if [ $? -eq 1 ]
then
# whatever you want
echo "Successfully created file"
exit 0
else
echo "Could not create file" >&2
exit 1
fi
I'm new in using yocto.
my environment is ubuntu 14.04,
Build Configuration:
BB_VERSION = "1.28.0"
BUILD_SYS "x86_64-linux"
NATIVELSBSTRING "Ubuntu-14.04"
TARGET_SYS "aarch64-fsl-linux"
MACHINE "ls1043aqds"
DISTRO "fsl-qoriq"
DISTRO_VERSION "2.0"
TUNE_FEATURES "aarch64"
TARGET_FPU ""
I get the following error when running :
bitbake fsl-image-minimal
(on every call to bitbake build )
=====================
DEBUG: Running export SSH_AUTH_SOCK="/run/user/1001/keyring-an3Qaa/ssh"; export PATH="/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/sources/poky/scripts:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043aqds/tmp/sysroots/x86_64-linux/usr/bin/aarch64-fsl-linux:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043aqds/tmp/sysroots/ls1043aqds/usr/bin/crossscripts:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043aqds/tmp/sysroots/x86_64-linux/usr/sbin:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043aqds/tmp/sysroots/x86_64-linux/usr/bin:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043aqds/tmp/sysroots/x86_64-linux/sbin:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043aqds/tmp/sysroots/x86_64-linux/bin:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/sources/poky/scripts:/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/sources/poky/bitbake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"; export HOME="/home/ymarko"; git -c core.fsyncobjectfiles=0 branch --set-upstream master origin/master
| DEBUG: Python function base_do_unpack finished
| DEBUG: Python function do_unpack finished
| ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 128, output:
| fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.
|
ERROR: Task 854 (/opt/disk1/LS1043-Install/SDK/QorIQ-SDK-V2.0-20160527-yocto/sources/poky/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb, do_unpack) failed with exit code '1'
NOTE: Tasks Summary: Attempted 306 tasks of which 298 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:
================================
Can you help please?
Try upgrading your version of git to 2.7.3. I was having the same problem and this fixed it
You need this patch in order to fix it.
Pay attention, you can't simply add "-to" as a suffix. The order of arguments also reversed.
Example how to use:
curl https://patchwork.openembedded.org/patch/145072/raw/ | git apply -v
I have a python script on server_A that connects to server_B via SSH and calls a local rsync command to reset a directory B with a fresh set of files. Then the script on A proceeds to rsync over additional set of files to B. My hope was to run this on a schedule in Rundeck. However, it is erroring on me every time during run with this output. What am I doing wrong?
Remote command failed with exit status 1
Failed: NonZeroResultCode: Remote command failed with exit status 1
Execution failed: 9 in project Test: [Workflow result: , step failures: {1=Dispatch failed on 1 nodes: [server_A: NonZeroResultCode: Remote command failed with exit status 1]}, Node failures: {server_A=[NonZeroResultCode: Remote command failed with exit status 1]}, flow control: Continue, status: failed]
Exit status 1 was returned by the command you called. What are you running?
I am executing Jenkins Job which Builds my .csproj file and execute few PS scripts.
Issue is I get a successful email even if my PS script fails,How should I tell my Jenkins Job to trigger me an email also if PS script is failing.
Error Logs-
Copy-Item : The process cannot access the file
'\\10.0.1.190\d$\Build\RPC\abcde.RPC.AirSearch\Common.Logging.Core.dll' because it is being used by another process.
At C:\Users\Administrator\AppData\Local\Temp\hudson9059014122834846757.ps1:3 char:1
+ Copy-Item "C:\AirSearchBnd\src\abcde.Air.Search.RPC.Host\bin\Release\*" "\\$en ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Copy-Item], IOException
+ FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.CopyItemCommand
[AirSearchBnd] $ powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Users\ADMINI~1\AppData\Local\Temp\hudson9149103993066004448.ps1'"
[SC] CreateService SUCCESS
SERVICE_NAME: AirSearchWindowsService
TYPE : 10 WIN32_OWN_PROCESS
STATE : 2 START_PENDING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 13784
FLAGS :
> C:\Program Files (x86)\Git\bin\git.exe tag -l RPCBUILD_6 # timeout=10
> C:\Program Files (x86)\Git\bin\git.exe tag -a -f -m Jenkins Git plugin tagging with RPCBUILD_6 RPCBUILD_6 # timeout=10
Pushing tag RPCBUILD_6 to repo Dev
> C:\Program Files (x86)\Git\bin\git.exe --version # timeout=10
using GIT_ASKPASS to set credentials
> C:\Program Files (x86)\Git\bin\git.exe push https://github.com/abcdeHoldings/abcde.Services.Air.Search.git RPCBUILD_6
Email was triggered for: Always
Sending email for trigger: Always
Request made to compress build log
Sending email to: abcde#software.com abcde#software.com abcde#software.com abcde#software.com
Finished: SUCCESS
The easiest way is to configure Jenkins to send e-mails on failed builds and in the Powershell step add the following at the end:
if ($error) { exit 1 }
The problem with Jenkins Powershell plugin is that it doesn't honor the errors that happen in Powershell, only the exit code of the shell itself, this will force build to fail and trigger the email.
There is an option of "Attaching Build Log". You can read the build log to see, if the ps script has failed.
I am attempting to set up Capistrano with a SilverStripe build and am running into a few troubles setting up the shared directories.
I set the linked_dirs in deploy.rb with the following:
set :linked_dirs, %w{assets vendor}
Since adding this line I get the following error:
[617afa7f] Command: /usr/bin/env mkdir -p /var/www/website/releases/20160215083713 /var/www/website/releases/20160215083713
INFO [617afa7f] Finished in 0.250 seconds with exit status 0 (successful).
DEBUG [88c3de20] Running /usr/bin/env [ -L /var/www/website/releases/20160215083713/assets ] as capistrano#128.199.231.152
DEBUG [88c3de20] Command: [ -L /var/www/website/releases/20160215083713/assets ]
DEBUG [88c3de20] Finished in 0.258 seconds with exit status 1 (failed).
DEBUG [3d61c1c4] Running /usr/bin/env [ -d /var/www/website/releases/20160215083713/assets ] as capistrano#128.199.231.152
DEBUG [3d61c1c4] Command: [ -d /var/www/website/releases/20160215083713/assets ]
DEBUG [3d61c1c4] Finished in 0.254 seconds with exit status 1 (failed).
INFO [3016a8cd] Running /usr/bin/env ln -s /var/www/website/shared/assets /var/www/website/releases/20160215083713/assets as capistrano#128.199.231.152
I am a mega noob when it comes to Capistrano and a semi noob when it comes to server configuration and permissions, so any pointers would be appreciated.
It probably hasn't actually failed. One thing to know about Capistrano is that (success) and (failed) are actually returning the result of the exit status, (success) if 0 and (failed) if non-0.
If we look at the command in question, it says that /usr/bin/env [ -L /var/www/website/releases/20160215083713/assets ] failed. This command is saying "return 0 if /var/www/website/releases/20160215083713/assets exists and is a link (-L). This fails, but that just means it returns non-0, thus the link needs to be created. Note that the next command also fails (-d) with asserting that the path is a directory. And the last line in your output is actually creating the link in question.
You can see the test in the Capistrano codebase here: https://github.com/capistrano/capistrano/blob/master/lib/capistrano/tasks/deploy.rake#L128
You can clean up and simplify the output with https://github.com/mattbrictson/airbrussh. This is developed by one of the primary Capistrano devs.
As a sidenote, similarly all the green text in your terminal is stdout and the red text is stderr. This can also be confusing.