Contributor testing fails with drone_step_0 : exit code 128

[e3b0c442]

• Gitea version (or commit ref): master 9002c51
• Git version: n/a, but 2.17.1
• Operating system: Ubuntu 18.04.2 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:
  https://gist.github.com/e3b0c442/59eb42f89913086bdd10e0380aa767c9

Description

When attempting to run contributor tests as outlined in CONTRIBUTING.md, the testing fails with drone_step_0 : exit code 128. Unfortunately there is no obvious reason for the failure, except that it seems to lie with MSSQL startup.

I tried running the test script linked in #6269 with no change.

I also tried running with drone-cli == 1.1.0 with the commend drone exec --event pull_request with no change.
...

Screenshots

n/a

[e3b0c442]

git bisect shows this issue was introduced with a27d5d2.

[e3b0c442]

Logs from the fetch-tags step:

[fetch-tags:L0:0s] + git fetch --tags --force
[fetch-tags:L1:0s] Host key verification failed.
[fetch-tags:L2:0s] fatal: Could not read from remote repository.
[fetch-tags:L3:0s] 
[fetch-tags:L4:0s] Please make sure you have the correct access rights
[fetch-tags:L5:0s] and the repository exists.

Looks like a bad git host key on the docker:git image?

[e3b0c442]

I was able to work around this issue by cloning https instead of git+ssh, however, I don't think it's unreasonable that people may prefer using ssh over https. I wonder if there is a way this can be enabled, but I can already see that if the host key issue is resolved, the fetch would still fail because of auth. I'll ponder this today.

I'm guessing the clone config item that previously existed was done outside of the container where the full SSH config/auth of the host was available.

[techknowlogick]

Drone clones via HTTPS (it also injects auth variables for cloning into the container which don't exist when running locally), I'm guessing you cloned via SSH (which is what you should do as git via SSH is better). The way this could get fixed is to exclude this step from running on pull_requests.