Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create .gitlab-ci.yml #858

Open
wants to merge 1 commit into
base: stretch-unstable
from
Open

Create .gitlab-ci.yml #858

wants to merge 1 commit into from

Conversation

@kay0u
Copy link
Member

kay0u commented Dec 1, 2019

The problem

No CI

Solution

I propose to add this file to use the gitlab-ci.

This file will run the postinstall of yunohost on a gitlab runner, and all the tests we wrote on https://github.com/YunoHost/yunohost/tree/stretch-unstable/tests and https://github.com/YunoHost/yunohost/tree/stretch-unstable/src/yunohost/tests.

You can see it in action here or here

To work, it needs a specific runner, available here mirrored on github here. Feel free to contribute on framagit, or if you want I can transfer this project on YunoHost organisation. If you have any question on how to configure the runner on a gitlab instance contact me, I'll be happy to help you. For your information I tested it on a Virtualbox running a debian stretch.

To implement this solution, there are many solutions:

  • Do not use gitlab-ci and work on an external solution as we do for CI_package_check.
  • Migrate right now on framagit.org, and mirror our repo on github. (With this solution we can have all benefits of Gitlab CI, but the migration cost is a big thing).
  • Mirror manually (webhook could do it?) our github projects to framagit.org. (With this solution we don't have automatic CI on PR)
  • Use gitlab.com which provides for free a mirror from github.com to gitlab.com, but it's free until March 22nd, 2020. (With this solution we have automatic CI on PR, but we have it for free for a limited period).

I'm opening the discussion.

PR Status

...

How to test

...

Validation

  • Principle agreement 0/2 :
  • Quick review 0/1 :
  • Simple test 0/1 :
  • Deep review 0/1 :
@frju365

This comment has been minimized.

Copy link
Member

frju365 commented Dec 1, 2019

Well It's very good to use gitlab-ci, but, I don't know if we agree with migrating to framagit after framasoft told users that they will close registration to most of their services in 1-2 years. Perhaps I'm wrong and it has been discussed (I was not here since 3-4 meetings, so I don't know).

For me ideal would be to mirror manually to framagit and perhaps other hosts and do test on framagit.

However, I don't understand why we couldn't have automatic CI test on PR with this solution ?

@kay0u

This comment has been minimized.

Copy link
Member Author

kay0u commented Dec 1, 2019

Well It's very good to use gitlab-ci, but, I don't know if we agree with migrating to framagit after framasoft told users that they will close registration to most of their services in 1-2 years. Perhaps I'm wrong and it has been discussed (I was not here since 3-4 meetings, so I don't know).

I didn't know that framagit was concerned about that. In that case we must discuss on which instance we want to move.

However, I don't understand why we couldn't have automatic CI test on PR with this solution ?

To have a proper solution, well integrated to GitHub, which trigger automatically tests and displayed on the PR like this for example (look CI in the PR), we need the paid version of gitlab mirror (free until march), I don't know exactly how to test PR from a fork with the solution base on a manual mirror.

@frju365

This comment has been minimized.

Copy link
Member

frju365 commented Dec 1, 2019

ok. Isn't this feature enable in community edition (dev edition) of gitlab ? Because perhaps other instance than gitlab.org have it (couldn't we do the same system with gitlab api ?).

However, if we move to framagit or another, we won't need it.

@yalh76

This comment has been minimized.

Copy link
Contributor

yalh76 commented Dec 2, 2019

Maybe another option would be to have our own gitlab + gitlab-runner. In that case we would not framasoft mirroring limitation.

For example, yunohost repo stays at github.
Our own gitlab can have a mirror of that repo and able to run runners automatically....

@kay0u

This comment has been minimized.

Copy link
Member Author

kay0u commented Dec 3, 2019

It's indeed a solution, the fact is that Gitlab needs a lot of resources, if we have a good server to host it, we can consider it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.