Determine GitLab CI status (enabled/disabled) based on .gitlab-ci.yml existence

• when someone push .gitlab-ci.yml - we should enable CI (by !1403 (merged))
• when someone removes .gitlab-ci.yml from default branch - we should disable CI

mentioned in merge request !1403 (merged)

We also shouldn't enable CI if .gitlab-ci.yml is pushed to a non-default branch, since this could be a feature branch that was created before it was deleted in the default branch.

Maybe we shouldn't enable/disable CI for the entire project based on .gitlab-ci.yml being pushed, but simply run it for branches that have it, and don't for branches that don't.

I don't think we need the project-wide CI-enabled status at all, it can simply be always-on.

Maybe we shouldn't enable/disable CI for the entire project based on .gitlab-ci.yml being pushed, but simply run it for branches that have it, and don't for branches that don't.

@DouweM that makes a lot of sense for me!

cc @ayufan

for keeping it simple, if someone pushes and old branch just run it, people should revoke credentials if they no longer want to deploy something

In IRC some users complained that they can't completly disable ci in their instance at the moment.
When this is decided based on the existence of the .gitlab-ci.yml file,
can we create a global git hook for this that prevents uploading it?

That way we can keep it simple and still satisfy the admins who don't want anyone to use gitlab ci for some reason. (corporate policy or something like that)

@haynes I don't like idea of allowing people to disable part of our application for everyone. It basically disable GitLab CI checkbox :( cc @sytses

when someone push .gitlab-ci.yml - we should enable CI (by !1403 (merged))

Not sure about that. Not everyone uses CI. What if someone clones a public GitLab repo with CI (and therefore a .gitlab.yml) and pushes this to its private GitLab server without CI?

@dzaporozhets well... you can already do this now with the git hooks.
disallow .gitlab-ci.yml as a file ending and you have that effect.
A seperate hook would just make it more obvious.

Not sure about that. Not everyone uses CI. What if someone clones a public GitLab repo with CI (and therefore a .gitlab.yml) and pushes this to its private GitLab server without CI?

Good point. That would leave the user with useless UI elements in their project...

Well lets be realistic. There is very little chance you are going to fork project with .gitlab-ci.yml file and not using CI but wanting to keep file. And for this people its ok to have a bit of useless UI elements in their project.

Lets think about how good it will work for most of people instead of how it does not for few.

@dzaporozhets

My idea:

1. By default we enable GitLabCiService for a new projects, just like Issues or Merge Requests. Maybe we should also enable it for all projects that doesn't have other CI service enabled.
2. If someone wants to disable build triggers he simply unticks Active in GitLabCiService, but data are still accessible for commits.
3. No logic when .gitlab-ci.yml is pushed or not.
4. Is someone doesn't want to use built-in CI, he deactivates GitLabCiService and enables Drone CI or something else.

We can put CI option in Project Settings in Features group:

@ayufan thanks. I will think about this option too

Existence of the file seems like a great way to do it, because there may be instances where we do not want to run CI for a particular branch -- e.g. gh-pages

In our case, we have an old branch that does not have any tests built for it, but it still needs occasional maintenance.

Perhaps at the very least, a disabled: true line in the yml?

Having it under project settings is acceptable to me.

@sytses @ayufan having it in Project Settings makes sense. Its not an external service but a built-in feature like Issues and Merge Requests. So I see it like this:

• Put CI in Project Settings under features like Issues or Wiki
• Enable CI by default for new projects
• Remove logic that enables CI with you push .gitlab-ci.yml file

Milestone changed to 8.2

I leave this up to @ayufan since he is more involved in CI development right now.

Reassigned to @ayufan

@ayufan I think project settings now has builds enable/disable right?

@sytses Yes.

I don't think " when someone removes .gitlab-ci.yml from default branch - we should disable CI" makes sense.

What if you want to start using GitLab CI? In this case you want to push a new yml file in a feature branch to test it before merging to master.

Status changed to closed

mentioned in merge request !14785