Contributor testing fails with drone_step_0 : exit code 128 #3415

New Issue

GiteaMirror · 2025-11-02T05:12:14-06:00

GiteaMirror commented

2025-11-02 05:12:14 -06:00

Originally created by @e3b0c442 on GitHub (Jun 3, 2019).

Gitea version (or commit ref): master 9002c5157b
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

Originally created by @e3b0c442 on GitHub (Jun 3, 2019).   - Gitea version (or commit ref): master 9002c5157b352afb944d0c6a5065deee1e8b113d - 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 - [x] 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

GiteaMirror added the type/testing label 2025-11-02 05:12:14 -06:00

GiteaMirror closed this issue

2025-11-02 05:12:14 -06:00

GiteaMirror commented

2025-11-02 05:12:15 -06:00

@e3b0c442 commented on GitHub (Jun 3, 2019):

git bisect shows this issue was introduced with a27d5d2b23.

@e3b0c442 commented on GitHub (Jun 3, 2019): `git bisect` shows this issue was introduced with a27d5d2b230e7b63a4b1959991d8b638527f48c6.

GiteaMirror commented

2025-11-02 05:12:15 -06:00

@e3b0c442 commented on GitHub (Jun 3, 2019):

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 commented on GitHub (Jun 3, 2019): 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?

GiteaMirror commented

2025-11-02 05:12:15 -06:00

@e3b0c442 commented on GitHub (Jun 3, 2019):

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.

@e3b0c442 commented on GitHub (Jun 3, 2019): 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.

GiteaMirror commented

2025-11-02 05:12:15 -06:00

@techknowlogick commented on GitHub (Jun 3, 2019):

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.

@techknowlogick commented on GitHub (Jun 3, 2019): 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.

GiteaMirror referenced this issue

2025-11-02 12:22:19 -06:00

[PR #3415] [MERGED] Add myself to TRANSLATORS #16928

Sign in to join this conversation.