This repository was archived by the owner on Nov 4, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2020. It is now read-only.
Simpler docker-compose setup for tests #223
Description
To run tests locally, a contributor needs to setup a gitlab instance (which is totally fine).
The suggested docker-compose is in gitlab_tests/test_v91/docker-compose.yml
I think we could leverage the documentation that Gitlab has and use one of their examples and docker containers:
https://docs.gitlab.com/omnibus/docker/README.html#install-gitlab-using-docker-compose
This should free up maintenance of those containers and we end up using the official gitlab ones.
Activity
Sudo-Kid commentedon May 17, 2017
My only issue with the Gitlab docker containers is that they don't go back as far as this library states we support. The Gitlab one only goes back to 8.13.6-ce.0 well the docker-compose file that I have in test goes back a bit further. It's this one https://github.com/sameersbn/docker-gitlab
Edit: I'm not apposed to the switch though if you want to get it up and running.
sijis commentedon May 18, 2017
I can spend some cycles to try and convert.
Is the issue supporting the the different API versions as they are related to gitlab versions?
Sudo-Kid commentedon May 18, 2017
We have a question that could be a bug open for as far back as 7.1
sijis commentedon May 18, 2017
As to understand, is that gitlab version supported?
What I'm trying to understand, is the library supporting all versions of the gitlab API or only v2 (or some version) and higher?
So if the support matrix is based on gitlab API versions, then the code, I would guess, is positioned in a way to handle different gitlab API versions separately. At a glance, it's hardcored to v3 and I don't see a way to specify my API version.
I'm not questioning the design just trying to better understand the requirements. I want to ensure I continue the projects vison appropriately with any PR / suggestion I have.
sijis commentedon May 18, 2017
As I thought about this a little, it reminded me of a project I worked on (https://github.com/gogoair/pyasgard) that dynamically built all the api endpoints available based on a file (endpoint.py). The idea could easily be adapted here to support multiple api versions (by adjusting the endpoint logic), I think. Again, this all depends on the support matrix. Is it gitlab versions or gitlab api versions?
Thanks for hearing me out.
Sudo-Kid commentedon May 18, 2017
My plan is to not drop support for anything already supported and currently 7.1.X is listed as supported with missing functionality.
We will need to add some way of supporting both V3 and V4 of the API before August roles around. I just need to review the API V4 docs to see how different they are.
Your PR's / suggestions are all very valid and appreciated. Also please do question the design if you find something you feel is wrong or out of place. Feed back can only make this project better.
Edit: To clarify it will be gitlab versions. I spoke with the gentleman that start this project and they can change from gitlab version to version.
Sudo-Kid commentedon May 18, 2017
My goal at the moment is to mimic the API for a version of Gitlab in the unittests using mock data.
What I have been doing as we add new tests is remove the mock calls and do a quick integration test with the version I have currently and use that data in the mock. This will allow us to quickly run our tests against all the different version when we update things. Though it doesn't provide the much needed integration tests.