Enable CI for gitlab when .gitlab-ci.yml is pushed
Make enabling CI as easy as pushing file.
Should be merged after !1402 (merged).
Fixes #2650 (closed). Part of #2594 (closed) and internal issue https://dev.gitlab.org/gitlab/gitlabhq/issues/2528
Merge request reports
Activity
Edited by username-removed-444I think that we should just ensure that ci_project is always created. It will resolve the
.gitlab-ci.ymlautomatically without the need for enabling the CI.-
@ayufan I would like to get rid of
ci_projectin future. We don't need it anymore. CI Commits should point toprojectinstead and settings can be stored in CI service or Project -
It will resolve the .gitlab-ci.yml automatically without the need for enabling the CI.
@ayufan we still need to enable service. Basically this MR does next:
- create Ci::Project model
- enable CI service
Edited by username-removed-444 -
@ayufan Or we can use
Ci::Projectas CI specific settings for any kind CI integration. In this case it makes sense to have ci_project always created. It really depends on CI integration and Commit Status API implementation. I think we can go either way. Lets have it discussed somewhere outside of this merge request because we need it merged anyway - does not matter what direction we choose in future.Edited by username-removed-444 Added 1 commit:
- aba9668a - Rescue rugged error when detect ci yml file
- Last reply by username-removed-444
-
@DouweM review? Please!
😃 Edited by username-removed-444 mentioned in merge request !1405 (merged)
55 55 56 56 @push_data = build_push_data(oldrev, newrev, ref) 57 57 58 # If CI was disabled but .gitlab-ci.yml file was pushed 59 # we enable CI automatically 60 if !project.gitlab_ci? && gitlab_ci_yaml?(newrev) 61 project.enable_ci(user) We don't support people disabling CI manually even though they have a
.gitlab-ci.yml? If they do, it will just be enabled again on the next push.Edited by Douwe Maan-
@DouweM hard one. I think they should remove file. Otherwise how we would know if they want CI enabled or not?
-
@DouweM I can imagine situation with people using GitLab CI and then switching to something else but there is no reason to keeping CI file.
@dzaporozhets In that case we should probably remove the
Enabledcheckbox forGitLab CIin services, because after this MR is merged it will no longer have any effect. We could replace it by text saying GitLab CI depends on.gitlab-ci.yml?
Added 1 commit:
- 0a57c3f6 - Refactor Project#enable_ci method
mentioned in merge request !1405 (merged)
-
In that case we should probably remove the Enabled checkbox for GitLab CI in services, because after this MR is merged it will no longer have any effect. We could replace it by text saying GitLab CI depends on .gitlab-ci.yml?
@DouweM No because there will be no way to disable CI.
Proper way now after this MR:
- remove
.gitlab-ci.ymlfile - disable checkbox
Also, should we automatically set ci_service.active to false when .gitlab-ci.yml is deleted?
@DouweM no because some old branches may not have
.gitlab-ci.yml. You don't want accidentally disable our CI by pushing to6-9-stableEdited by username-removed-444 - remove
-
@DouweM actually we can check if file was in previous commit but was removed in new commit. But I think our problem right now is people who can not easily enable CI - not people who want to disable it.
no because some old branches may not have .gitlab-ci.yml. You don't want push to 6-9-stable to disable our CI
@dzaporozhets Ah yeah, good point.
Maybe GitlabCiService should always be on, and do a check if
.gitlab-ci.ymlexists in the branch in question before actually executing. Otherwise, the service could accidentally be enabled again, when someone pushes to a feature branch that was created before.gitlab-ci.ymlwas deleted in the master branch.The issue I have with the proposed behavior is that we will have two things that determine if CI is enabled or not, the checkbox and the
.gitlab-ci.yml, that interact with eachother in not completely obvious ways. I would love to just have the presence of.gitlab-ci.ymldetermine if CI is enabled or not.-
I would love to just have the presence of .gitlab-ci.yml determine if CI is enabled or not.
@DouweM makes sense. I propose I will create separate merge request that disable CI if yml existed but
removedin main branch. Because I have 2 more merge requests waiting review based on this. @dzaporozhets Sounds good, this MR looks good.
mentioned in issue #2714 (closed)
-
@DouweM I created issue - #2714 (closed)
mentioned in issue #2715 (closed)
mentioned in commit b859506b
mentioned in commit a58c6e9a
