In my gitlab CI runner I'm setting up the yaml to call a python script. Currently the script fails to connect to an HTTP server (this is expected behavior). The resulting exception is caught in the python script and it exits with a -1. However the CI runner hangs indefinitely. What could the problem be?
The issue was a misunderstanding of how the gitlab ci works. In the script tag I was first booting up a system that the hanging executable did work on. When the executable fails it expects the child processes to be cleaned up before proceeding. I was expecting the ci to call into after_script which is where I was doing the clean-up.
Related
I'm trying to setup the gitlab ci shell runner. I've used the docker runner before successfully but now I'd like to use another docker container within my testing routine and therefore switched to the shell runner.
After registering I'm running into an exception:
ERROR: Job failed (system failure): prepare environment: exit status 1. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
So, I went through the linked material but that didn't cure the problem. Now, I verified that the gitlab-runner user exists and it has access to docker (needed to run the docker test container). Also the gitlab-runner user is part of the docker group. I can also --login, fire up the /bin/bash without problems.
Still, all I get from the runner side is the the enigmatic message above. What other checkups to I need to do to track down this issue?
The careful reader will find the answer:
"A common failure is when you have a .bash_logout that tries to clear
the console."
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 having a problem deploying an EB instance with a custom .ebextensions file. This is the relevant part in that file:
container_commands:
01_migrate:
command: 'python db_migrate.py'
02_npm_build:
command: 'npm install && npm run prod'
As you can see, these commands are for migrating my PostgreSQL database (via a Flask backend) and building my React .jsx files.
If I leave these commands out, the deployment completes perfectly well. However, once I put them in, looking at the eb-activity.log it stalls at this part forever (as far as I can tell):
[2017-04-10T02:39:24.106Z] INFO [3023] - [Application deployment app-613e-170409_223418#1/StartupStage0/EbExtensionPostBuild] : Starting activity...
I also get this message on the Health overview in the console (this is after 1 day):
Performing application deployment (running for 1 day).
I have also tried to deploy it without those container_commands, and then including it back after the successful initial deployment. Then I get the same error message as before in eb-activity.log, and I also get this message on the Health overview:
Incorrect application version "app-2a3d-170409_214923" (deployment 1). Expected version "app-2a3d-170409_214923" (deployment 1).
Which is very strange because those two versions referenced are the same versions. I don't know what this means!
I found a solution.
Remove all you container_commands from .ebextensions/
Go ssh to instance, kill process with.
sudo killall python
Then Deploy new version without container_commands.
And start debuging all your container_commands, one by one on ssh..
Have fun.
I have a working vagrant + ansible setup to provision my digital ocean, it was running on api v1, but when DO deprecated it I got an error message telling me there was no support for v1 anymore. After a research I found out I needed to upgrade to ansible 2.0 + update my digital_ocean.py since the older one was still using client_id and api_key, the new one however now uses the api_token.
Basically I've updated
1.digital_ocean.py which I got from ansible repo module
2. digital_ocean.ini to contain the api_token
3. updated my api token from DO to make sure it's using the new one
but when I execute my ansible playbook I initially got this error
ERROR! The file provisioning/inventory/staging/digital_ocean.py looks like it should be an executable inventory script, but is not marked executable. Perhaps you want to correct this with `chmod +x provisioning/inventory/staging/digital_ocean.py`?
So naturally had to chmod +x it but when I did I get a new error which is
ERROR! The file provisioning/inventory/staging/digital_ocean.py is marked as executable, but failed to execute correctly. If this is not supposed to be an executable script, correct this with `chmod -x provisioning/inventory/staging/digital_ocean.py`.
ERROR! Inventory script (provisioning/inventory/staging/digital_ocean.py) had an execution error:
ERROR! provisioning/inventory/staging/digital_ocean.py:3: Error parsing host definition ''''': No closing quotation
The next one seem to be json parsing related, my only problem is that it's on line 3 which if you check on the code itself are still on the comment side
https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/digital_ocean.py
I received both errors mentioned and solved them with the following:
The dopy related error was due to the fact that my python and pip were installed differently. dopy was installed via pip which was installed via homebrew. I was using the system python. When I installed python via homebrew, the script found dopy just fine.
Regarding the second error, that is the result I got when not setting the DO_API_TOKEN. I set mine in the command itself with:
DO_API_TOKEN=<api_token> ansible -i digital_ocean.py all -m ping
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