modulesync 4.0.0 #93
modulesync 4.0.0 #93
Conversation
ekohl
force-pushed
the
modulesync
branch
4 times, most recently
from
a2cc006
to
0e702b9
Compare
|
I mostly got things to work, but it can't reach the gitlab service. I suspect the created beaker container is different network than the service container. I don't see an easy way to change the network for beaker-docker though. Another issue is the ruby task helper for the unit tests. The relative require doesn't work well. |
.github/workflows/ci.yml
Outdated
| services: | ||
| gitlab: | ||
| image: gitlab/gitlab-ce | ||
| ports: | ||
| - 80:80 |
There was a problem hiding this comment.
The Docker health check only waits for the container, it does not check for the API responding on http/80.
https://github.com/voxpupuli/puppet-gitlab_ci_runner/pull/93/checks?check_run_id=1456486776 shows this race condition.
The Travis configuration called the setup-gitlab.sh script which invokes an endless waiting loop.
Probably this can be fixed by adding a new step which calls this script in the steps below, after checking the network settings. cc @bastelfreak
There was a problem hiding this comment.
@dnsmichi do you have permissions to push to this PR? If so, it's fine to add commits to this PR. We can always clean them up before we merge.
There was a problem hiding this comment.
@ekohl I'm testing my assumption in a fork currently. Thanks for the poke, I should actually have permissions :)
There was a problem hiding this comment.
Seems I was wrong, it is just the network and the DNS record just not exposed by the services setting in GitHub actions.
According to the docs it should work though: https://docs.github.com/en/free-pro-team@latest/actions/guides/about-service-containers#running-jobs-in-a-container
There was a problem hiding this comment.
That was also my impression. The only thing I can think of is that the services and what beaker-docker launches uses different networks. Note that the DNS could not be resolved (I tried without the IP in hosts hack) which may also indicate that they're isolated.
There was a problem hiding this comment.
I did not know that the acceptance tests are run in Docker by beaker, but I just remembered a similar chat with @DavidS about Gitpod, Docker and acceptance tests.
https://github.com/voxpupuli/voxpupuli-acceptance
I'd guess you need to manually start the Docker container for gitlab/gitlab-ce then, and build your own isolated network. Or there is a way to "pre start" the beaker container with GitHub actions.
The docs and community threads advise against docker-compose and own setups though, maybe this scenario won't work with actions and the services setting.
There was a problem hiding this comment.
One solution might be to launch a gitlab-ce container via beaker-docker so they end up in the same network, like https://github.com/voxpupuli/puppet-vault_lookup/blob/master/spec/acceptance/nodesets/docker/docker.yml does.
The docker module fails on EL7 so the tests started to fail on this.
The latest docker module hard fails on this since it's detected as Red Hat < 7.
No description provided.