4 ms·

It looks like these guys are picking up ideas from the travis-ci.org project, which uses a ".travis.yml" file for configuration- https://github.com/tedivm/Stas

by tedivm 13y ago

It looks like these guys are picking up ideas from the travis-ci.org project, which uses a ".travis.yml" file for configuration- https://github.com/tedivm/Stash/blob/master/.travis.yml https://github.com/tedivm/Stash/blob/master/.travis.yml This has huge advantages, especially in conjunction with things like git or github. With travis ci it's trivial for testing to be setup on new branches or even forks. We use Jenkins at work, and I'm excited to extend that level of functionality there.

rurounijones 13y ago
Yea, this seems overcomplicated for something that can easily be smacked into a .travis.yml file with simple syntax. Dream result would be what happened with RVM and RBenv merging their simple "select ruby version" files in that Travis, CircleCi, Jenkins etc. all agreed on a generic .build.yml file syntax and we could just use that.
- arohner 13y ago
  While a standard .build.yml file sounds nice, I'm not sure we understand the problem well enough to figure out what the optimal syntax would look like. This matters because the syntax has large implications for 1) how simple your build process is 2) how much overhead your CI system can take care of, for you. For example, at Circle, we're still experimenting with yml syntax for user-specified parallelization commands. Each different syntax we've looked at has different implications for what kinds of problems are simple, and what kinds of problems are expressible, using the syntax. So yes, standards, but not yet :-)
michaelneale 13y ago
Supporting a .travis.yml config file (or similar) should be relatively easy - as you mention - the multibranch stuff is probably the bigger "improvement" for Jenkins.
- stephenconnolly 13y ago
  Ahem! The initial commit includes: https://github.com/jenkinsci/literate-api/blob/master/src/main/java/org/cloudbees/literate/impl/YamlProjectModelBuilder.java https://github.com/jenkinsci/literate-api/blob/master/src/ma... however it is not completed yet ( see the comment in https://github.com/jenkinsci/literate-api/blob/master/src/main/resources/META-INF/services/org.cloudbees.literate.spi.v1.ProjectModelBuilder https://github.com/jenkinsci/literate-api/blob/master/src/ma... ) We had to prioritise which would get released first and I found the Markdown format more fun personally, so it got more love... plus you didn't give the YAML one any love either

by tedivm 13y ago

rurounijones 13y ago

Yea, this seems overcomplicated for something that can easily be smacked into a .travis.yml file with simple syntax. Dream result would be what happened with RVM and RBenv merging their simple "select ruby version" files in that Travis, CircleCi, Jenkins etc. all agreed on a generic .build.yml file syntax and we could just use that.

arohner 13y ago
While a standard .build.yml file sounds nice, I'm not sure we understand the problem well enough to figure out what the optimal syntax would look like. This matters because the syntax has large implications for 1) how simple your build process is 2) how much overhead your CI system can take care of, for you. For example, at Circle, we're still experimenting with yml syntax for user-specified parallelization commands. Each different syntax we've looked at has different implications for what kinds of problems are simple, and what kinds of problems are expressible, using the syntax. So yes, standards, but not yet :-)

michaelneale 13y ago

Supporting a .travis.yml config file (or similar) should be relatively easy - as you mention - the multibranch stuff is probably the bigger "improvement" for Jenkins.

stephenconnolly 13y ago
Ahem! The initial commit includes: https://github.com/jenkinsci/literate-api/blob/master/src/main/java/org/cloudbees/literate/impl/YamlProjectModelBuilder.java https://github.com/jenkinsci/literate-api/blob/master/src/ma... however it is not completed yet ( see the comment in https://github.com/jenkinsci/literate-api/blob/master/src/main/resources/META-INF/services/org.cloudbees.literate.spi.v1.ProjectModelBuilder https://github.com/jenkinsci/literate-api/blob/master/src/ma... ) We had to prioritise which would get released first and I found the Markdown format more fun personally, so it got more love... plus you didn't give the YAML one any love either