Testing instructions in CONTRIBUTING.md need to include drone-cli version and disk space requirements

[stevegt]

The drone exec command in CONTRIBUTING.md isn't working again as of 7548037:

drone exec --local --build-event pull_request

This is using a newly-downloaded drone 1.0.4, which no longer supports the --local flag.

We last fixed this in #4055. If anyone seeing this has the correct command for non-maintainers to run, just let me know and I'll fix CONTRIBUTING.md again.

Meta-wise, does anyone have any ideas about how to somehow test the testing instructions to ensure that the drone command in CONTRIBUTING.md stays up to date? Having this broken has got to be discouraging contributors. The only bright idea I've had so far is to put the command itself into a separate file that is referred to by CONTRIBUTING.md and also automatically executed during regression testing.

[adelowo]

Gitea .drone.yml is for version of Drone <= 1.0. 1.X only has a release candidate, not an official release.
Maybe that's the issue

[stevegt]

Which version of drone are folks using now? I upgraded to 1.0.4 (which is what someone would get if following CONTRIBUTING.md today) after finding that gitea no longer works with drone 0.8.5. I started a bisect run late last night to see if I could figure out when 0.8.5 broke, but that failed with bad git state; haven't had another go at that yet and it might be orthogonal anyway.

[adelowo]

I don't know but it is definitely a version lesser than 1.0, Maybe @techknowlogick or @lunny can confirm that

[techknowlogick]

I’m pretty certain we are on 0.8.9, the go-gitea/infrastructure repo would be able to confirm. I’m on mobile currently so I can confirm.

[stevegt]

go-gitea/infrastructure/ansible/roles/drone/defaults/main.yml:drone_server just says drone/drone:0.8 -- latest in the 0.8 series is 0.8.6 according to https://0-8-0.docs.drone.io/cli-installation/.

But 0.8.6 fails with current master HEAD (ad86b84):

2019/03/06 18:44:53 Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/opt/mssql/bin/sqlservr\": stat /opt/mssql/bin/sqlservr: no such file or directory": unknown

This is the same error message I was getting with 0.8.5. Running a bisect right now to see if that tells me anything.

[techknowlogick]

The latest in the 0.8 drone branch is 0.8.10 (although it was mistakenly tagged as 0.8.9) the Drone docs may be out of date.

[stevegt]

No prebuilts past 0.8.6 showing at https://github.com/drone/drone-cli/releases/, so if it does turn out to be that then we'll need to send people to the drone build instructions. I'll build and try 0.8.10.

[stevegt]

We must be talking about two different things -- these are the tags in the drone-cli repo -- 0.8.6 is the latest in the 0.8 series:

v0.4.2
v0.6.0
v0.7.0
v0.8.0
v0.8.1
v0.8.2
v0.8.3
v0.8.4
v0.8.5
v0.8.6
v1.0.0
v1.0.1
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.0.6
v1.0.7

[stevegt]

So far in bisect runs the most recent commit that passes contributor drone testing is b686bd0 -- that commit was 30 Oct 2018.

[adelowo]

So it's been broken since then?

I usually just use go test -tags='sqlite sqlite_unlock_notify' code.gitea.io/gitea/models -run=RegexThatMatchesMyTest though

[stevegt]

@adelowo I have no idea. This is just what bisect is telling me so far; could be something with my setup, or it could be that people simply aren't testing before submitting a PR. We spent some time back in #4053, #4055, #4070, #4071 etc. getting this working again, so not being able to run the tests again is discouraging. I've spent most of my spare time this week trying to understand what's going on now.

If this is really broken, I'm sure we've chased away a few contributors -- I spent a lot of extra time trying to test before submitting #6244 this week, for instance. I finally just crossed my fingers and slammed it in, but I'm not comfortable doing that at all.

[stevegt]

I've run drone 62 times on two different machines so far, including a fresh ubuntu 18.10 at GCE -- results so far are consistent with drone exec --local --build-event pull_request ceasing to work in October 2018. Everything before October passes, and everything after October fails. But the errors and horizon are both unstable -- October tests that sometimes fail also sometimes pass, and the errors vary. I'm starting to suspect a race condition or resource constraint.

[stevegt]

Arg. Okay, looks like resource constraints are at least one culprit. It looks like the drone tests need several Gb now, and don't handle running out of disk space gracefully.

And it so happens that starting in October, a default GCE machine with a 10 Gb disk became just barely not big enough for the tests to fit. The AWS default of 8 Gb should have been hit on or before October as well.

If we were to do #6269, a disk space precheck should be one of the first things the wrapper script should do.

That still leaves the drone-cli 1.0.4 version incompatibility, but that can be taken care of by #6269 as well.

Still testing to see if there's anything else; have an army of GCE machines working on this now.

[stevegt]

Interesting. Just noticed that drone 1.0.0 was released in the same time frame, on 21 Oct 2018, which would have broken CONTRIBUTING.md's testing instructions and would have helped to mask the disk space growth thing.

[stevegt]

PR #6305 contains more complete testing instructions that reference the 0.8.6 drone-cli version and the newer disk space requirements. This makes the testing instructions more complicated, so it also contains a script which automatically takes care of both. Discussion of the script itself should probably go into #6269.

[stevegt]

PR #6305 now only contains updates to the instructions in CONTRIBUTING.md -- if accepted, that PR would close this issue.