My Cloud build fails with a timeout on npm test, and no useful information is sent to stdout. A complete log can be found in a file, but I couldn't find a way to ssh in the cloud build environment.
Already have image: node
> project-client#v3.0.14 test
> jest
ts-jest[versions] (WARN) Version 4.1.0-beta of typescript installed has not been tested with ts-jest. If you're experiencing issues, consider using a supported version (>=3.8.0 <5.0.0-0). Please do not report issues in ts-jest if you are using unsupported versions.
npm ERR! path /workspace/v3/client
npm ERR! command failed
npm ERR! signal SIGTERM
npm ERR! command sh -c jest
npm ERR! A complete log of this run can be found in:
npm ERR! /builder/home/.npm/_logs/2020-11-09T07_56_23_573Z-debug.log
Since I have no problem running the tests locally, I'd like to see the content of that 2020-11-09T07_56_23_573Z-debug.log file to hopefully get a hint at what might be wrong.
Is there a way to retrieve the file content ?
Ssh in a cloud build environment?
Get npm to print the complete log to stdout?
Some way to save the log file artifact to cloud storage ?
I had a similar issue with error management on Gitlab CI and my workaround is inspired from there.
The trick is to embed your command in something that exit with a return code 0. Here an example
- name: node
entrypoint: "bash"
args:
- "-c"
- |
RETURN_CODE=$$(jtest > log.stdout 2>log.stderr;echo $${?})
cat log.stdout
cat log.stderr
if [ $${RETURN_CODE} -gt 0 ];
then
#Do what you want in case of error, like a cat of the files in the _logs dir
# Break the build: exit 1
else
#Do what you want in case of success. Nothing to continue to the next step
fi
Some explanations:
echo $${?}: the double $ is to indicate to Cloud Build to not use substitution variables but to ignore it and let Linux command being interpreted.
The $? allows you to get the exit code of the previous command
Then you test the exit code, if > 0, you can perform actions. At the end, I recommend to break the build to not continue with erroneous sources.
You can parse the log.stderr file to get useful info in it (the log file for example)
Related
I'm using Laravel Forge to run a simple deploy script. npm run build calls 'vue-cli-service build'.
Script below. The script 'ends' on
DONE Build complete. The dist directory is ready to be deployed.
INFO Check out deployment instructions at https://cli.vuejs.org/guide/deployment.html
but the thread does not quit, which causes issues in forge (e.g. thinks it's timed out or failed when it hasn't).
How do I do the equivelant of ctrl-c in a terminal once this has finished, in the deploy script? I've seen threads on trap SIGINT / trap etc. but I'm still not really sure how to implement it.
It may be that I just include the exit callback fix noted here: Vue-cli-service serve build completion callback?
git pull origin $FORGE_SITE_BRANCH;
npm run build;
( flock -w 10 9 || exit 1
echo 'Restarting FPM...'; sudo -S service $FORGE_PHP_FPM reload ) 9>/tmp/fpmlock
if [ -f artisan ]; then
$FORGE_PHP artisan migrate --force
fi```
Try out to add Daemon termination command to the end of your deployment script
$FORGE_PHP artisan horizon:terminate
I'm trying to run Cypress test in Gitlab. Below is the sample script. After executing 'npm run Cypress', if there is any test case fail, it exits with 'exit code 1' and next two commands won't run.
Is there a way I can execute next two commands. Next two commands, generates consolidated Jnuit and HTML report.
script:
- cd ./cypress
- npm ci
- npm run Cypress
- npm run mochawesome
- npm run junit:merge
I have tried below mentioned solution but no luck.
script:
- cd ./cypress
- npm ci
- npm run Cypress || exit 0
- npm run mochawesome
- npm run junit:merge
script:
- cd ./cypress
- npm ci
- npm run Cypress
after_script:
- npm run mochawesome
- npm run junit:merge
output Image:
One way would be instead of mentioning the exit code, which seems to be dynamic you can directly echo something after the || operator.
npm run Cypress || echo \"The previous command has some errors..Continuing\"
Using the after_script approach actually should work fine as you can see from this minimal example:
# .gitlab-ci.yml
test:
image: alpine
script:
- echo "Hello after_script!" > test.txt
- exit 1
after_script:
- cat test.txt
Output:
$ echo "Hello after_script!" > test.txt
$ exit 1
Running after_script
Running after script...
$ cat test.txt
Hello after_script!
Cleaning up file based variables
ERROR: Job failed: exit code 1
Also, you can consider using set +e and set -e to disable/enable exit on error.
I'm trying to debug a CI pipeline and want to create a custom logger stage that dumps a bunch of information about the environment in which the pipeline is running.
I tried adding this:
stages:
- logger
logger-commands:
stage: logger
allow_failure: true
script:
- echo 'Examining environment'
- echo PWD=$(pwd) Using image ${CI_JOB_IMAGE}
- git --version
- echo --------------------------------------------------------------------------------
- env
- echo --------------------------------------------------------------------------------
- npm --version
- node --version
- echo java -version
- mvn --version
- kanico --version
- echo --------------------------------------------------------------------------------
The problem is that the Java command is failing because java isn't installed. The error says:
/bin/sh: eval: line 217: java: not found
I know I could remove the line java -version, but I'm trying to come up with a canned logger that I could use in all my CI-Pipelines, so it would include: Java, Maven, Node, npm, python, and whatever else I want to include and I realize that some of those commands will fail because some of the commands are not found.
Searching for the above solution got me close.
GitLab CI: How to continue job even when script fails - Which did help. By adding allow_failure: true I found that even if the logger job failed the remaining stages would run (which is desirable). The answer also suggests a syntax to wrap commands in which is:
./script_that_fails.sh > /dev/null 2>&1 || FAILED=true
if [ $FAILED ]
then ./do_something.sh
fi
So that is helpful, but my question is this.
Is there anything built into gitlab's CI-pipeline syntax (or bash syntax) that allows all commands in a given step to run even if one command fails?
Is it possible to allow for a script in a CI/CD job to fail? - suggests adding the UNIX bash OR syntax as shown below:
- npm --version || echo nmp failed
- node --version || echo node failed
- echo java -version || echo java failed
That is a little cleaner (syntax) but I'm trying to make it simpler.
The answers already mentioned are good, but I was looking for something simpler so I wrote the following bash script. The script always returns a zero exit code so the CI-pipeline always thinks the command was successful.
If the command did fail, the command is printed along with the non-zero exit code.
# File: runit
#!/bin/sh
"$#"
EXITCODE=$?
if [ $EXITCODE -ne 0 ]
then
echo "CMD: $#"
echo "Ignored exit code ($EXITCODE)"
fi
exit 0
Testing it as follows:
./runit ls "/bad dir"
echo "ExitCode = $?"
Gives this output:
ls: cannot access /bad dir: No such file or directory
CMD: ls /bad dir
Ignored exit code (2)
ExitCode=0
Notice even though the command failed the ExitCode=0 shows what the ci-pipeline will see.
To use it in the pipeline, I have to have that shell script available. I'll research how to include it, but it must be in the CI runner job. For example,
stages:
- logger-safe
logger-safe-commands:
stage: logger-safe
allow_failure: true
script:
- ./runit npm --version
- ./runit java -version
- ./runit mvn --version
I don't like this solution because it requires extra file in the repo but this is in the spirit of what I'm looking for. So far the simplest built in solution is:
- some_command || echo command failed $?
I am working on a project with a windows machine, and I have a few npm scripts like this:
"start" : "./foo/bar"
When I try to run npm run start I get this error:
.\foo\bar is not recognized as an internal or external command,
operable program or batch file.
I noticed the forward slash has been flipped to a backslash for windows, but also if I run this command on its own the bash terminal will interrupt them as 'escapes' and return:
bash: .foobar: command not found
The file runs ok in the terminal if I use ./foo/bar or .\\foo\\bar but not if I use these in the npm script.
What can I do to have this working in Windows? Furthermore is there a way to write it to be compatible for Win/Mac/Linux?
It works when you first do a cd with normal slashes (npm/nodejs seems to resolve this depending on the OS), then you only have to specify the file.
"scripts": {
"not-working": "scripts/another-folder/foo.cmd",
"working": "cd scripts/another-folder && foo.cmd"
},
So this is the only thing I see on failed build. When running npm scripts on a cli, you usually see more than the exit status. Is there some option to view the entire cli output instead of this pseudo log?
I contacted support and was told to cat the debug log in order to see the output.
#!/bin/bash
set -ex
cat $(find $HOME/.npm/_logs -name '*-debug.log')