Set up GitLab CI/CD for GitHub

[dzhoshkun]

Travis CI has been set up as part of #105, and is working. However even for the quicktest it takes on the order of 30 mins to run, due to the lack of GPUs.

A viable option for using GPUs is GitLab CI/CD for GitHub. Setting it up boils down to the following steps:

1. Connect GitHub project to GitLab
2. Create a personal access token on GitHub and activate it on GitLab
3. Register the Adelie runner on GitLab

Here is first test case where this was set up: #105 (comment)

We should also decide what to do with the #105 changes. @wyli Do you see any value in keeping Travis?

In any case, we should probably continue using tox, as it allows for easy multi-Python-version testing. But maybe we should address this in another issue, to keep things simple.

[wyli]

Travis I think yes, because Gitlab to Adelie access is not immediately available after the move

[dzhoshkun]

• Connecting GitHub project to GitLab fails with An error occurred while importing project: Error: Request failed with status code 422

Managed to do it by changing the group visibility to public.

[dzhoshkun]

• how does this work for forks?

[dzhoshkun]

@wyli See the above green tick :) Please click and confirm that you can access it on gitlab.com

Also, I've added a TODO to check how this integration works with forks. If you can think of anything else that needs to be checked, please add a TODO for it.

[dzhoshkun]

@wyli I've dug a bit deeper into the GitLab integration with GitHub for CI/CD. It looks like it's set up only to build the tip of the branches of the original repository, and not of any forks. This might be due to security reasons. However being able to run CI/CD pipelines for pull requests is in my opinion essential with regards to catching regressions. So I've submitted a feature request on GitLab.

In the meantime, I suggest the following to enforce CI:

1. We add all active developers as "contributors" to this repository so that they can work on branches directly and not forks.
2. We merge each PR from forks onto a new branch tagged with that PR number (e.g. pr-123-bla-bla-bla), which should trigger the pipelines for that branch.
   • if checks pass: merge the PR into the main branch, and delete the PR branch
   • if checks fail: fix the code to make the checks pass

What do you think?

Adding @tomdoel to this discussion as well.

[wyli]

Sounds good @dzhoshkun, I'll update CONTRIBUTING.md and close this issue.