Skip to content
Snippets Groups Projects
New issue look: Off

Zero Config CI

    • Closed Issue created by username-removed-55219 @kelvinmutuma

    Dev: https://dev.gitlab.org/gitlab/gitlabhq/issues/2528

    When I add a .gitlab-ci.yml file The project should be setup in GitLab CI automatically So I can already see the commit status in the merge request that adds the yml file

    Making CI so easy to use will enable use to make GitLab CI much more popular.

    What is needed before we can start:

    1. Enable all docker images by default https://dev.gitlab.org/gitlab/gitlab-ci/issues/334
    2. Automatically assign a shared runner https://dev.gitlab.org/gitlab/gitlab-ci/issues/333

    What we should do in this issue is:

    1. When a yml file is present ensure the project is set up in CI
    2. Remove the 'add project' screen in GitLab CI as the homepage of CI and replace it with a list of active projects and the notice that to add a project you should add a .gitlab-ci.yml file

    I would also like to see the commit status API https://dev.gitlab.org/gitlab/gitlabhq/issues/2467 and our shared runner offering https://dev.gitlab.org/gitlab/gitlab-ci/issues/322 but it is not strictly necessary for this.

    Valery

    What if user does not have CI server? and use gitlab instance like a mirror?

    User still needs to configure CI, like, setup runners and so on. When all this stuff is done, user can click button "Add project" on the CI dashboard and project will be configured automatically. In fact, the change you proposed will eliminate this step only (click "Add project" button).

    But anyway, I like the idea of ability to enable CI from GitLab side.

    Job

    I think that one step makes a difference.

    In fact, we could even add a button to GitLab: "Add your Project to GitLab CI"

    Which, on click, brings you to a prefilled .gitlab-ci.yml file.

    I think it's a great idea :thumbsup:

    Valery

    It also means that we should have some default CI server. Because currently GitLab can work with unlimited amount of different CI servers. In other words, it is needed to decide where this setting will be stored from user perspective.

    Sytse

    valery The configuration of runners and so on are done by the admin, not the user. For users of properly maintained installations (such as gitlab.com) it will be zero config. I love the idea of a button in GitLab that brings you to a prefilled .gitlab-ci.yml file based on your type of project. Good point about needing to know the url of the CI server. I'm sure this can be solved in Omnibus since we also automated the autentication configuration part. Maybe @marin can comment

    Marin

    I don't know if I followed the idea closely here so I will try my best:

    I'm sure this can be solved in Omnibus since we also automated the authentication configuration part. Maybe @marin can comment

    What omnibus currently does is generate oauth settings for connection between GitLab -> GitLab CI. User still needs to Add project once they go to GitLab CI or in Project Services enable GitLab CI explicitly. Project configuration between GitLab and GitLab CI is out of omnibus-gitlab scope unless a setting gets added to either GitLab or GitLab CI config.

    Sytse

    marin The idea is that we write a GITLAB_CI_URL into gitlab.rb, this can be used by GitLab to send the .gitlab-ci.yml file to GitLab CI. On receiving that file GitLab CI can set things up automatically.

    Marin

    sytse We have ci_external_url, would that do? For example, if we look at the setup of GitLab.com and public ci server, value of this in gitlab.rb is ci_external_url https://ci.gitlab.com. This value is also used to authorise GitLab and GitLab CI automatically.

    Sytse

    marin I think that will do. kamil what do you think that will work?

    Kamil

    Yes. It will work. We still have to think about some mechanics:

    1. What data would be send from GitLab to CI?
    2. The project on CI needs to be created anyway: We need to create project on CI side and the CI token needs to be assigned on GitLab side. Who will be responsible for that?

    Sytse

    1. Webhooks that includes .gitlab-ci.yml in the payload?
    2. Right now GitLab CI does this in the name of the user via oAuth. Since there is no user involved it must be done automatically. I think GitLab should configure itself but I'm not sure.

    Dmitriy

    :thumbsup: for idea. if we know CI url that should be possible to implement. Can we add project from GitLab in CI without user involvement? Maybe implement some API. sytse I have feeling that with such tied integration over time it makes no sense to have separate application for GitLab and Coordinator. Too many repeating variables and cross-links. And if we implement commit status API it will be basically a duplicate of commits data that we already have in CI.

    Sytse

    dzaporozhets funny, kamil has exactly the same feeling. I'm OK with either, I'm seeing more and more duplicated work between CE and CI (storing credentials, configuration, interface) so I'm not against integrating them.

    Kamil

    dzaporozhets I proposed something like that some time ago :)

    Sytse

    monorail

    Dmitriy

    sytse microservices!!! When instead one working app you have 10 non-working :smiley:

    kamil cool. Lets make a plan for merge Coordinator in CE

    Sytse

    Creating new public issue for that: gitlab-org/gitlab-ce#2164

    Dmitriy

    sytse awesome. Thats what I wanted to propose!

    Sytse

    CI autostart discussed in gitlab-org/gitlab-ce#2650

    I think the only thing left to do is having new project use shared runners by default https://dev.gitlab.org/gitlab/gitlab-ci/issues/333

    cc/ @sytses @dzaporozhets @JobV @marin @ayufan @vsizov

    Designs

    Child items ...

    • Activity

    Please register or sign in to reply