How can I make sure I have set up my drone server successfully? I thought it can be tested by opening the IP address with a web browser (In my case, it’s http://192.168.222.7:8000).
I use the recommended way to generate a DRONE_SECRET which is in the form of xxxx-yyyyy-zzzzz-wwww-N. Is that correct? I expected it to be a base64 number or whatever.
Given that IP of my machine is 192.168.222.7, and the exported port is 8000 for the Drone server, Is the DRONE_SERVER ws://192.168.222.7:8000/ws/broker?
Is the value of DRONE_SECRET for the Drone agent same as the DRONE_SECRET specified for the Drone server?
I encountered the follow messages:
$ docker logs drone-agent
1:M 19 Dec 06:03:18.038 * connecting to server ws://192.168.222.7:8000
1:M 19 Dec 06:03:18.038 # connection failed, retry in 15s. websocket.Dial ws://192.168.222.7:8000: dial tcp 192.168.222.7:8000: getsockopt: connection refused
It’s up-and-running now. I spent some time to figure out the differences between 0.4 and 0.5.
Now the last thing which would likely be broken is my handwritten rsync plugin. It would take some time to know whether it works or not.
note that 0.4 and 0.5 plugins are not compatible. 0.5 plugins use environment variables to pass fields to the plugin instead of a large JSON blob. Porting shouldn’t be too difficult, though.
The build failed at 33 mins after it started and the logs from the web UI is cut off in the middle despite I have set DRONE_MAX_LOGS=10 for the Drone Agent. Maybe that was not enough for a big project like an Android BSP? Or should I set it for the Drone Server as well?
Also, the web UI was very unresponsive when the build was running. The Google Chrome prompted about killing the tab several times (due to unresponsiveness).
If you’re running OS X, I’ve noticed Safari is able to deal with big logs a lot better than Chrome.
I had a build that ran for 8 minutes but shouted 80MB to stdout. Run it locally and pipe the output to a file. That way you can check the filesize to see what your DRONE_MAX_LOGS should be.
It would be even better, however, to reduce your log size somehow. Nobody is going to go through 10+MB of garbage to find something on a CI server.
If you have a failing build but you don’t know why, run it locally (using Drone exec) in a more verbose mode.
It can store all the logs now after following your advice.
The size of log is about ~16MB with 2>&1 | tee build.log. The web UI is literally unusable with that amount of data (even very difficult to ‘click’ the restart button). But anyway, it’s finally settled down