Bonjour,
The fedeproxy repository in Go was bootstraped with the gitea codebase. Changes from the gitea main branch will be merged (not rebased) on a regular basis.
Changes to fedeproxy will follow the regular merge-request workflow. They must be designed to reduce the likelihood of conflicts when the gitea main branch is merged.
The CI will be a GitLab-CI file that runs the drone CLI.
Cheers
The first merge of the Gitea main branch was done and I’ll schedule to make one every week so that it does not lag behind. @pilou would you like to take turns doing that?
No, i don’t.
The GitLab runner for the CI has a docker executor by default, with the sources mounted from a temporary docker volume. Since drone jobs are also using docker, they will fail to mount the volume of the source because they are not found on the docker host.
A solution would be to docker inspect the docker container running the CI job to figure out on which docker volume the sources were stored and then call drone exec --volume thefoundvolume:/drone/src.
A simpler solution is to run the tests from a GitLab runner that has a shell executor created with something similar to the following in /etc/gitlab-runner/config.toml and associated to a specific tag (shell for instance) so that other jobs do not accidentally use it.
[[runners]]
name = "shell-exec"
url = "https://lab.fedeproxy.eu"
token = "[redacted]"
executor = "shell"
[runners.custom_build_dir]
Care must be taken to remove .bash_logout and grant permissions to use docker:
$ rm /home/gitlab-runner/.bash_logout
$ usermod -aG docker gitlab-runner
The gitlab-ci.yml can then explicitly require to run jobs in the executor that has the shell tag.
Yep !