Add support for Elm about travis-yml HOT 8 CLOSED

Can I suggest we look at supporting both:

elm: 1.2.3

and

elm:
  version: 1.2.3
  test: 4.5.6

from travis-yml.

@joshk how would that look like for matrix expansion?

elm: 1.2.3 (at least in other languages) would normalize to elm: ['1.2.3'] (an array with one value)

are you suggesting this?

elm:
  - version: 1.2.3
    test: 4.5.6
  - version: 1.2.4
    test: 4.5.7

from travis-yml.

@svenfuchs you are a star for pointing this out, because now i see four options, which I would like your thoughts on (we could support one or multiple of these formats):

1. Single Elm version selection

elm: 1.2.3

2. Single Elm and test version selection:

elm:
  version: 1.2.3
  test: 4.5.6

3. Multi Elm and test version selection: Matrix expansion (9 jobs):

elm:
  version: [1.2.3, 1.2.4, 1.3.1]
  test: [4.5.6, 4.5.7, 5.1.1]

4. Multi Elm and test version selection: Specific definition (2 jobs):

elm:
  - version: 1.2.3
    test: 4.5.6
  - version: 1.2.4
    test: 4.5.7

My thoughts:

• We should do option one, simple shorthand for simple scenarios.
• I like option two for its structure, and not polluting the root namespace.
• I think I like option 3 because it allows for simple matrix expansion.
• I don't think we should do option 4, as this is possible with specific Job specifications (jobs.include), but I'm open to it.

from travis-yml.

@joshk sorry, missed this. thanks @carlad for the hint!

@joshk i agree, i think.

essentially this is what we have with other languages except traditionally we would have had elm_version and elm_test (or elm_test_version). i do like the proposal to use a namespace instead (i'd like to namespace other things more in the future, too)

i also agree 4 wouldn't be great as this isn't something we do for other languages/things, and adding this to Gatekeeper (i.e. without travis-yml in place) would be a huge mess (on top of the huge mess that we already have), so i think i'd strongly object.

one thing to keep in mind though is that we don't have any matrix expansion keys in nested namespaces so far afaik. so that might require some additional work definitely in Gatekeeper, in travis-yml, and possibly in Web (not too sure)

from travis-yml.

Anything I can do to help unblock the discussion?

from travis-yml.

@svenfuchs so just to confirm, you are also happy with option 3 that @joshk mentions?

from travis-yml.

@carlad yes, we're in agreement here.

we'd support all of 1-3, but not 4, either eventually or immediately. travis-yml would expand the formats 1 and 2 into the default format 3. i'm not sure if we want to do this work in Gatekeeper, too ... or require the use of travis-yml for this (there are other considerations about doing that, i guess)

also, we need to keep the caveat in mind that having an expansion key nested in a namespace is not something that they system supports out of the box. we'll have to make changes to travis-yml, Gatekeeper, and Web for this.

from travis-yml.

#87

from travis-yml.