CONTRIBUTING.md tells new contributors to run 'drone exec', which attempts several maintainer/owner operations

[stevegt]

CONTRIBUTING.md asks new contributors to run drone exec. This isn't possible without several API keys, including those of gitea maintainers/owners. None of these keys are mentioned in CONTRIBUTING.md, so it's hard to tell which are for maintainers and which are worth being set up by a contributor. As a result, the process of finding and removing the related stanzas from .drone.yml to try to get drone to run leads the user to inadvertently attempt several maintainer/owner operations, such as pushing new images to dockerhub:

[docker_docs:L341:124s] + /usr/local/bin/docker tag 00000000 gitea/docs:latest
[docker_docs:L342:124s] + /usr/local/bin/docker push gitea/docs:latest
[docker_docs:L343:124s] The push refers to a repository [docker.io/gitea/docs]
[docker_docs:L344:125s] dcb9aa504a9c: Preparing
[docker_docs:L345:125s] 97d75450208b: Preparing
[docker_docs:L346:125s] 00ce309518aa: Preparing
[docker_docs:L347:125s] f295bdb1762a: Preparing
[docker_docs:L348:125s] c9e8b5c053a2: Preparing
[docker_docs:L349:125s] denied: requested access to the resource is denied
[docker_docs:L350:125s] time="2018-05-26T21:13:44Z" level=fatal msg="exit status 1"

See #3977 for related discussion of crowdin, discord, and codecov API keys.

Not sure if the right answer is to modify CONTRIBUTING.md to tell users to run tests individually, add a Makefile stanza to make that easier, or alter the drone run.

To reproduce:

1. Log into a new Linux machine or VM where you have none of your maintainer API keys or other credentials installed.
2. Follow CONTRIBUTING.md up to and including the part where you run drone exec.
3. Remove stanzas from .drone.yml as they fail, mostly due to API keys that you don't have. You'll wind up with something that looks like
   drone.yml.gz.
4. Hit the above docker push error and stop out of concern.

[axifive]

Need run drone exec --local --build-event "pull_request".
It works fine

[stevegt]

Ah, I get it. Now I see what drone's step conditions are for -- thanks. But running drone exec --local --build.event pull_request still fails in coverage; haven't figured this one out yet:

[generate-coverage:L0:0s] + make coverage
[generate-coverage:L1:2s] gocovmerge integration.coverage.out  > coverage.all;\
[generate-coverage:L2:2s] 
[generate-coverage:L3:2s] 2018/05/27 03:39:49 failed to parse profiles: open integration.coverage.out: no such file or directory
[generate-coverage:L4:2s] Makefile:147: recipe for target 'coverage' failed
[generate-coverage:L5:2s] make: *** [coverage] Error 1
[generate-coverage] exit code 2

This is in a clean clone as of 2eabf18.

[axifive]

Strangely, my drone has completely gone through all the stages

[stevegt]

BTW the coverage errors I mentioned above were caused by the ancient version of drone CLI that we were leading people (including me) to install. There went my Saturday... Fixed in #4071, and local drone run completes successfully now. Thanks all!