I am using Azure Devops to build and deploy my git repo to a third party vps. I do this by logging into the server from Azure Devops through SSH, executing a shell script to pull git repo, and build it with ie. vue-cli and Laravel.
When the bash script is executed I receive a lot of errors on nearly all commands although everything is succeeding - can anyone tell me how to get rid of these unless something is really failing (would be nice to fail if npm build exit with code 1 for instance).
See screenshot below.
Screenshots are only really helpful for visual issues. You can use PasteBin or etc to share long logs if necessary.
According to this issue Azure just follows the lead of whatever shell it's running code in. So, in Bash it continues unless explicitly told to stop.
To easily change this behavior you can add set -e (or set -o errexit) at the start of your script. The errexit option causes Bash to exit as soon as a command/etc returns a non-zero exit code.
Another worthy addition is the set -o pipefail option. If you've got any pipes like command1 | command2 this will return the first non-zero exit code from a chain of pipes of any length as the result. So, if command1 fails above but command2 succeeds it would return the failure code from command1 instead of overwriting it.
Finally, set -u (or -o nounset) causes an error when unset variables are encountered during parameter expansion. If running in a non-interactive shell, it will also exit.
Many scripts combine these by running set -euo pipefail at the beginning to stop them from running after the first problem is encountered.
If you want to explicitly force a bash script to exit you can use || and && accordingly. The expression command || exit will exit if the command fails and command && exit will exit if the command succeeds.
This seems to be one bug starting from npm V.3.10.8. You can check this discussion.
As a workaround you can add this script to package.json and run the command with --no-optional switch:
"optionalDependencies": {
"fsevents": "*"
},
Also, there's possibility that your NPM version is too old. You can use Node.js tool installer task with version spec = 12.x to install higher node.js and npm versions.
Related
I am trying to run algolia for the first time but it seems that there is something wrong with my environment. I followed the detailed explanation here https://community.algolia.com/jekyll-algolia/getting-started.html.
I installed and configured everything that is needed from the previous steps but when I run the command
ALGOLIA_API_KEY=xxxxxxxxxxxxxx bundle exec jekyll algolia
I get an error:
'ALGOLIA_API_KEY' is not recognized as an internal or external command,
operable program or batch file.
I have been rereading the documentation for both jekyll and angolia but couldn't find anything that could be helpful.
Since you're running on Windows, you cannot set an environment variable for your command like you can do on UNIX.
As advised in this question, Setting and using variable within same command line in Windows cmd.exe, I believe you could use
set ALGOLIA_API_KEY=xxxxxxxxxxxxxx && bundle exec jekyll algolia
I'm having an odd issue with the awsebcli package when running it on Gitlab's pipeline CI system.
When I run eb deploy locally, the command succeeds (or fails) much as expected. When I run it as part of the CD scripts I've written, it runs successfully (i.e. returns an exit code of 0) but doesn't actually trigger the deployment. No errors are returned - in fact there's no text output from the command at all.
Can anyone suggest what could be going wrong here?
I am starting a ruby command from a batch file using STAF.
STAF $TESTMACHINE process start command ruby "C:\MyProject\scripts\MasterScript.rb" WAIT SAMECONSOLE RETURNSTDERR RETURNSTDOUT WORKDIR "C:\MyProject\scripts"
This batch file is triggered by a Hudson job. But my observation is that the print/puts of the ruby files appear in the hudson console only after the completion of the execution of the ruby script [Hudson job]. This way I can not make out if something is going wrong in the script execution unless the job completes.
Also, I understand that if I remove RETURNSTDERR RETURNSTDOUT, the ruby script's output is displayed in the STAF console on the target machine. So STAF is the one which is sending back the ruby outputs to the hudson console.
Now can I use any option with STAF to get the ruby output spontaneously to the hudson console?
Thanks for reading this lengthy question :)
You can use SSH instead of STAF for such task.
It seems with STAF it's a little bit tricky and could be done with OUTPUT option.
If you have shared storage, for example NFS share called /nfs on hudson server and d:\nfs on Windows, the following hudson job should work:
STAF $TESTMACHINE process start command ruby "C:\MyProject\scripts\MasterScript.rb" WAIT SAMECONSOLE RETURNSTDERR RETURNSTDOUT WORKDIR "C:\MyProject\scripts" OUTPUT "d:\nfs\hudson.log" &
tail --pid=$! -f /nfs/hudson.log
My NAnt builds run fine locally on a developer machine, and locally on the command line of the Hudson server, but they will not run in my configured Hudson project.
The console output when I run a Build via the Hudson web UI is similar to the following :
Started by user anonymous [workspace]
$ sh -xe
C:\WINDOWS\TEMP\hudson8104357939096562606.sh
C:\WINDOWS\TEMP\hudson8104357939096562606.sh:
fork failed: no error [1] Archiving
artifacts Finished: SUCCESS
I have another project configured properly that runs fine so I know the NAnt plugin is setup properly in Hudson, and that NAnt is on the system path.
Can anyone suggest possible causes as to why this build won't run?
The problematic build may be configured to Execute a Shell script, rather than Execute a Windows Batch file.
Copy the command from the existing build step (the Execute Shell Script) and remove the step. Then add a new step to Execute a windows Batch File and paste the command.
Trigger the build and observe the results.
(I asked and answered this since it took me quite a while to figure out how I had mis-configured this particular build. Hopefully it'll save time or give ideas to other people trouble-shooting automation..)
I am using the following code
#!/usr/bin/expect -f
#!usr/bin/expect
#package require Expect
puts "Hello world"
spawn ssh xyz#172.31.112.182
expect -nocase "password:"
send "abc123\r"
puts "done"
while executing, it throws error
Hello world
invalid command name "spawn"
while executing
"spawn ssh xyz#172.31.112.182"
(file "temp.tcl" line 9)
whats the wrong in my code
remove '#' before package require Expect.
The problem you've got is that while it is running in Tcl (I recognize that format of trace), the Expect package (which provides the spawn command) is absent for some reason. The first thing to do is to make the requirement for the Expect package explicit by uncommenting that package require line. That may be enough to fix your problem in itself, but if not it will complain about the package not being available. If it's not available, that means either that it just isn't installed, or that it's not being found. The former is... obvious to fix. :-) The latter is resolved by putting a line like this before that package require:
lappend auto_path /full/path/to/Expect/package/installation
Note that if you run the script with the expect program instead of the tclsh program, that package require will be done for you automatically. You're obviously not doing that…
Try running under tcl interpreter (!/usr/bin/tcl) and import Expect.
Did you installed Expect on your PC?
Please run the following command on your PC to check if Expect is available.
$which expect
/usr/bin/expect
sudo apt-get update -y
sudo apt-get install -y expect
which expect
Run the above commands respectively. If installed correctly, "which expect" will show "/usr/bin/expect" as an output. Run your script after installation,