Add dotnet-ci Integration

[OmarTawfik]

@mmitche

[OmarTawfik]

test ci please

[mmitche]

LGTM

[forki]

Groovy?

[smoothdeveloper]

@forki apparently continuous integration is jenkins based: https://github.com/dotnet/dotnet-ci/blob/master/docs/CI-SETUP.md#how-does-the-net-ci-model-work

[forki]

Yep.

I hope we can keep it as a super thin layer that shells out. Sad that they
don't use yaml like the other CI servers.

(also sad that we didn't get FAKE in...)
On Jan 6, 2016 09:40, "Gauthier Segay" [email protected] wrote:

@forki https://github.com/forki apparently continuous integration is
jenkins based:
https://github.com/dotnet/dotnet-ci/blob/master/docs/CI-SETUP.md#how-does-the-net-ci-model-work

—
Reply to this email directly or view it on GitHub
#852 (comment)
.

[mmitche]

@forki That's mostly because the job DSL language that creates jobs is in groovy. You could put a yaml layer on top of it if you wanted to though. However, the power of the scripting language is the ability to create wide combinations of jobs in relatively little code. For instance, CoreFx and CoreCLR have around a hundred jobs apiece. There are workflows that run on multiple machines, etc. This is a lot easier to do in the scripting language.

[forki]

I don't question the power of a scripting language. forget about the comment ;-)

[mmitche]

@forki I will say that for 'simple' workflows though, the yaml approach is better, but working with what we have :)

[enricosada]

README badges!!!! 😄

[enricosada]

@forki jenkins has lot of options, depends on plugins, from ui based to groovy.
For example i really like the literate plugin using a md file, for simple workflow

It really depends on what jenkins plugin you use for build matrix, versioning, artifacts, etc, but the flow is always the same, a build script inside repo is called after the jenkins job choose parameters.

Maybe with better build scripts... 😄