Added Travis-CI compatibility layer

[ayufan]

WARNING: This is WIP, please do not merge. This is preliminary work which still requires significant changes: i.e. better handling build matrix in terms of database representation and views.

This Pull Request adds Travis-CI support in GitLab CI. Most of the features already work: build matrices, languages, OSes. In order to test these changes at least this PR is required: gitlabhq/gitlab-ci-runner#99. It uses Travis-CI libraries: https://github.com/travis-ci/travis-build and https://github.com/travis-ci/travis-yaml to create build matrix and generate shell script. Travis images can be built using https://github.com/travis-ci/travis-images or using my script: https://github.com/ayufan/travis-images/blob/master/build_docker_templates.

• Use Travis::YAML to generate build matrices
• Use Travis::Build to generate build scripts
• Fetch .travis.yml from GitLab repository
• Support for limiting runners with OS and Language support
• Support for runners which can handle only build for project
• Added 'Build Now' view which allows to force build
• When using 'Deploy' in 'Build Now' try to fetch .release.yml first

[mistresseve666]

👍

To the GitLab team, what are the chances of something like this to be accepted? It covers a few key areas that are being requested on the feedback site, and adds even more.

[Wachiwi]

@robodude666 Regarding the chance of something like this to be accepted the following will be the first step to take:

Please keep the change in a single MR as small as possible. If you want to contribute a large feature think very hard what the minimum viable change is. Can you split functionality? Can you only submit the backend/API code? Can you start with a very simple UI? The smaller a MR is the more likely it is it will be merged, after that you can send more MR's to enhance it.

-- Merge Request Guidelines

[ayufan]

@Wachiwi it's agreed with @dosire to push this as one large change for now, we will later work on splitting PR into chunks

[ayufan]

I'm also thinking about introducing jobs which will take part of builds role. Job will identify one build variant which will be sent to runner. Build take a role to group all jobs for specific commit. However, this is a big change, so I will have to wait for while. We can later think about chaining jobs: waiting before some of the jobs finish.

[mistresseve666]

@Wachiwi I'm talking more from a dependency point of view. Will creating dependencies to travis-ci packages be acceptable, considering it's a competing product?

@ayufan Will this compatibility layer also provide an updated build log that automatically collapses large sections of stdout like Travis-CI?

[ayufan]

@robodude666 I made it yesterday. However, it's not top notch. I think that ansi2html should be rewritten to javascript. https://github.com/ayufan/gitlab-ci/commits/topic/build_trace_folding

Travis-CI License allows it:
https://github.com/travis-ci/travis-build/blob/master/LICENSE
https://github.com/travis-ci/travis-yaml/blob/master/LICENSE

[houndci-bot]

Redundant use of Object#to_s in interpolation.

[dzaporozhets]

@ayufan I am closing this as a result of our discussion during the call.

[dzaporozhets]

Reasons why this was declined for community:

Travis.yml file

We are moving in different direction than Travis. We have difference in architecture that we find simpler.

Runner: clone repo, run tests & send output to coordinator
Coordinator: get output from runners and show it to user.

Thats why all build scripts should be configured via UI. Its more user friendly and matches current architecture when coordinator does not know anything about repository.

Runners changes

We should not change runner code until we have a really good reason. No need to add any complexity in runner code. It should be simple lib that run process and submit output via API.

[CyBeRoni]

Closing this is a bad idea.

It should be simple lib that run process and submit output via API.

I agree with that principle but having a runner environment that isn't static is bad for testing; I don't want the results from one test (which might install software) to influence the result of another (which might need software installed, but doesn't do it, yet it works because an earlier unrelated test installed it).

These patches would easily allow an unchanging runner environment to be used, much like Travis, without much effort.

[ayufan]

I agree with you. We may do it even better by using current build scripts, but by extending runner to use docker environment (or any environment at all).