Matrix Builds / Sub-Builds / Parallel Builds about gitness HOT 78 CLOSED

@os12 you will be able to invoke distinct scripts using the following notation:

build:
  image: go
  commands:
     - ./scripts/$$script
matrix:
    script: 
      - ci-debug
      - ci-opt
      - ci-opt-asan

and you could inject environment variables like this:

build:
  image: go
  commands:
     - export $$env
matrix:
    env: 
      - VARIANT=debug
      - VARIANT=opt
      - VARIANT=opt INSTRUMENTATION=asan

I'm pretty confident that all use cases are supported with the proposed yaml format and injection strategy proposed in #6 (comment).

from gitness.

good question. what do you think the .drone.yml should look like?

Here are the use cases I'd like to cover with sub builds:

• I want to test code against python2.7 and python3.3 and pypy
• I want to test code against three different docker images (same thing as above)
• I want to test code against python2.7 and redis2.6 and redis2.8
• I want to test code against python2.7, but I want to run 3 "sub builds" in parallel to reduce execution time

Here are some design questions:

• How do the above use cases impact deployments?
• If we have 3 sub builds which one should be responsible for executing the deployment?
• If we have 1 sub builds responsible for deployment, should it wait for the other 2 to pass?
• How do we represent all of this in the yaml
• How do we display the results in the UI (e.g. website design)

Although I think we can draw some inspiration from Travis I do not want to just copy their approach as I think it would limit our capabilities. With Travis your build is heavily tied to a language:

language: go

With Drone your build is tied to a Docker image. The image defines the environment. This may seem like a nuance, but this is really important. Drone doesn't care about language. Drone will never dictate which languages you can or cannot use. We need a yaml file that is re-imaged for Docker.

I consider this a high priority feature. Hopefully we can get a discussion started here and come up with some options.

from gitness.

@bradrydzewski great use cases here. Wasn't even thinking about those. One thing that comes to mind is having Docker images that contain all possible versions. For example, A Python Docker image that contains 2.6-3.3 and pypy. User could reference which version to use:

script:
  - pip2.7 install -r requirements.txt
  - python2.7 setup.py test
  - pip3.3 install -r requirements.txt
  - python3.3 setup.py test

I'm pretty sure this isn't the best way. You mentioned sub builds and that got me thinking about:

image: base-image
env:
  - DEBUG=true
builds:
    build:
        image: python
        env:
            - SECRET_KEY=123
        script:
          - pip install -r requirements.txt
          - python setup.py test
        services:
          - redis
notify:
  email:
    recipients:
      - [email protected]
      - [email protected]

But building matrixes, like on Travis, with this will possibly end up with a massive .drone.yml. Travis makes that pretty cool, I just set the versions of the language and additional environment variables. Every environment variable items in the env array trigger individual builds. I think we might be able to find a way to do that with Drone's philosophy.

image:
    name: python
    config:
        versions:
            - 2.7
            - 3.3
env:
  - DEBUG=true SECRET_KEY=123
script:
  - pip install -r requirements.txt
  - python setup.py test
services:
  - redis
        config:
            versions:
                - 2.6
                - 2.8
notify:
  email:
    recipients:
      - [email protected]
      - [email protected]

This example would trigger 4 sub builds one for each version of python with each version of the redis service. Hope this is somewhat useful.

from gitness.

I really like your suggestion. Instead of "versions" we could call them "tags" which is consistent with the docker terminology:

image:
    name: python
    tags:
      - 2.7
      - 3.3

Do you have any suggestions for a notation that would split a build into parallel tasks? For example, I only want to test against Python2.7, but my tests take a long time, so I want to break them up into suites and run in parallel.

We anticipated this change, so our database already supports sub-builds / matrix builds. The real challenge here is the yaml :)

from gitness.

Good discussion. Just a suggestion though: perhaps, rename the issue because this problem isn't exclusively a python concern. This issue is pertinent to other environments such as NodeJS, Ruby, Erlang/Elixir, etc.

Also, 👍 - with Travis (as much as I love it), trying to build https://github.com/exercism/exercism.io/blob/master/.travis.yml is difficult. You have to circumvent the magic with multiple bootstrap files or the equivalent.

By leaning on docker images (or dockerfiles), seems like single-language builds would be less magical in general and multi-language builds would be less obtuse.

from gitness.

Hi all.

Got directed to this thread by @bradrydzewski giving my £ 0.02
I think the travis matrix would be a good starting point to begin with. ( see https://github.com/elasticsearch/puppet-elasticsearch/blob/master/.travis.yml as example )

Most important parts i think are :

• enabling different versions of the selected language
• When having the same ENV variable, add it to the matrix ( In my case PUPPET_VERSION, but if you have an other one, add it to the matrix )
• Allowing failures for certain cases ( combo of language version and ENV variables )

For deployments its hard to choose when its allowed to do it ( when a certain test passed or all of them )

That's all i can think of at the moment.

from gitness.

For another example of a tool that is thinking along these lines, check out Test Kitchen's platforms and suites:

http://kitchen.ci/docs/getting-started/adding-platform
http://kitchen.ci/docs/getting-started/adding-suite

While Kitchen is really thinking in terms of OS versions, the issue here in terms of Rubies or Pythons is really the same thing a level up the stack.

from gitness.

I don't think the ability to paralellize one build is linked to this issue. As if you want to do that, you need to define (independant) sub-units of your build, which is pretty orthogonal to the idea of running the build multiple time on different environments ...

Try not to bloat this issue to much by adding every possible future feature to it. I think it's better to keep busy on one aspect at a time.

I think you came up pretty far there by defining to more aspect there: We need the ability to select different 'tags' of an image, and/or the ability to select different version of a service, and/or the ability to run the build with a different set of environments variables, and so on ...

I believe all of them could be implemented independently from each other ...

from gitness.

@benallard I definitely agree

I had a great discussion with an Ops lead that suggested adding a matrix section, where the axis could be defined. What does everything this of this proposal?

image: python:$$python_version
env:
  - DEBUG=true
  - SECRET_KEY=123
  - DJANGO=$$django_version
script:
  - pip install -r requirements.txt
  - python setup.py test
services:
  - redis:$$redis_version

matrix:
  python_version:
    - 2.7
    - 3.2
  redis_version:
    - 2.6
    - 2.8
  django_version:
    - 3.0
    - 4.0

this would end up producing 8 different sub builds. I think it is probably the most flexible design, but I'd love to hear what others think.

note that the matrix parameters should be handled in a similar manner to private environment variables. They can be injected directly in the script (using find / replace) using the $$ convention. They would also be injected directly into the build as environment variables.

from gitness.

Looks good to me @bradrydzewski :-) i would go for that.

from gitness.

@bradrydzewski that's pretty interesting right there. It took me a moment to figure out that the matrix defines the variables and its values, but I think it definitely covers all the cases we previously discussed.

from gitness.

Looks perfect to me. This is the only features keeping me from using drone right now!

On Feb 25, 2014, at 4:20 PM, Brad Rydzewski [email protected] wrote:

@benallard I definitely agree

I had a great discussion with an Ops lead that suggested adding a matrix section, where the axis could be defined. What does everything this of this proposal?

image: python:{{ python_version }}
env:

• DEBUG=true
• SECRET_KEY=123
• DJANGO={{ django_version }}
  script:
• pip install -r requirements.txt
• python setup.py test
  services:
• redis:{{ redis_version }}

matrix:
python_version:
- 2.7
- 3.2
redis_version:
- 2.6
- 2.8
django_version:
- 3.0
- 4.0
this would end up producing 8 different sub builds. I think it is probably the most flexible design, but I'd love to hear what others think.

—
Reply to this email directly or view it on GitHub.

from gitness.

An other important addition is to be able to tell which combo's are allowed to fail.
In my case im running multiple Puppet versions against different Ruby versions.
Some earlier puppet versions don't work against Ruby 2.0.0 and fail.

I was thinking of the following:

Allow all ruby 2.0.0 cases to fail:

allowed_fail:
    ruby:
      - 2.0.0

Allow Ruby 2.0.0 with Puppet 2.7.0 or 3.0.0 to fail

allow_fail:
  ruby_version:
    - 2.0.0
    puppet_version:
      - 2.7.0
      - 3.0.0

Any thoughts about it?

from gitness.

You should pay attention not mixing a notification issue with a fundamental architecture one ...

Do you don't want those test to run, or do you just don't care about their result ? If the former, this should be analysed there, if the later, we should figure out later about the right way to perform this.

Anyway, to extend on your idea, it should be possible to define sub-matrices where the build should not be performed.

I suggest the following syntax:

matrix:
  python_version:
    - 2.7
    - 3.2
  redis_version:
    - 2.6
    - 2.8
  django_version:
    - 3.0
    - 4.0
  except:
    -
      python_version: [2.7]
      django_version: [3.0, 4.0]
    -
      redis_version: [2.6]
      django_version: [4.0]

This would run all the builds except the 6 excluded ones ...

from gitness.

This was merged with #159, so I'm continuing discussion here. My use case is as follows:

• There are multiple projects in the same git repository. These projects have different build systems, languages, names, and teams. I'd prefer to keep all the projects within the same git repo because of many shared pieces of code.
• For each project, I'd like to see details about which tests are passing and failing, and at which point which tests began to fail.

It seems like the proposals so far don't solve the problem of having multiple projects per git repository. They do deal with the problem of multiple builds per project.

Personally I'm skeptical the ideal solution involves sticking purely with yaml files. As a user, I'd prefer if Drone stayed out of the way as much as possible and allowed me to script the configuration if I wanted:

for python_version in [2.7, 3.2]:
  for redis_version in [2.6, 2.8]:
    for django_version in [3.0, 4.0]:
      addBuild(
         variantName = "py=%f, redis=%f, django=%f" %
           (python_version, redis_version, django_version),
         image = "....")

Once again, this does not solve the multiple-projects-per-repository problem (maybe we should continue that discussion in #159), but hopefully it helps with the discussion at hand.

from gitness.

@gonzojive I don't think this works too well because then you are just picking a scripting language (looks like Python) which creates two problems:

1. You shouldn't use code to describe data when the actual data (a markup file) will do fine.
2. Non-Python users will be left wondering why Python was chosen over their favorite language.

As a side note, if this were a viable solution then something other than nested for-loops would be more readable:

python_version = (2.7, 3.2)
redis_version = (2.6, 2.8)
django_version = (3.0, 4.0)
for python, redis, django in itertools.product(python_version, redis_version, django_version):
  add_build(python, redis, django)

from gitness.

I think you can stick with a configuration language, but it'd be good to allow scripting if desired. You can do it in a way that leaves the choice of programming language up to the user.

Perhaps the .drone.yml file can include a line like

drone-config-script:
- ruby gen-build-plan.rb > $OUT

from gitness.

@gonzojive this is definitely a more advanced use case you are proposing. This project is still very young (0.1 alpha release) and the immediate focus is on the more simple use cases that serve 80+% of users. I'm happy to revisit this request in a few months once the project is further along.

from gitness.

How about the use case of builds with separate deployments? For instance, it might be convenient to keep a project's source and website in the same repo. Then, when the build happens, the website is built and deployed to its server and the source is compiled and that result is uploaded to s3.

from gitness.

@justone If both of the source and the website sit on the same branch you can use deploy and publish plugin together in a single .drone.yml file.

from gitness.

@fudanchii Interesting idea. I didn't realize you could have a deploy and a publish in the same file. I wonder if it's possible to have multiple deploys of different types in the same .drone.yml file. Like a git and an ssh deploy, each going to different places. I suppose that if #201 is merged, you can have one bash deploy that sends application artifacts to one location and the generated website to another.

If multiple builds can be specified, I think it would be good for there to be an environment variable injected into the build so that any deploy or publish can know which one it's working on.

from gitness.

Wanted to add my +1 to this. I'd like to have a situation where I can define multiple images (Ubuntu versions) to test my software. Something like this makes sense to me:

image:
  - ubuntu:14.04
  - ubuntu:12.04

from gitness.

@justone yes you can have multiple deployment entries in the yaml (ie ssh and git). We loop through each entry and execute.

from gitness.

@bradrydzewski Adding my +1 to this. I'd also like to see this support parallelization. I think it would be a subsection to 'script', where you define which container to run a test in. I've modified your example above to illustrate it:

image: python:{{ python_version }}
env:
  - DEBUG=true
  - SECRET_KEY=123
  - DJANGO={{ django_version }}
script:
  container1:
    - pip install -r requirements.txt
    - python setup.py test
  container2:
    - pip install -r requirements.txt
    - python setup.py test
services:
  - redis:{{ redis_version }}
matrix:
  python_version:
    - 2.7
    - 3.2
  redis_version:
    - 2.6
    - 2.8
  django_version:
    - 3.0
    - 4.0

Love to hear other's thoughts on this too.

from gitness.

I was speaking with someone yesterday about this, and he suggested we might approach this with multiple YAML docs in a single .drone.yml

Something like this:

---
image: mischief/docker-golang
env:
  - GOPATH=/var/cache/drone
script:
  - go build
  - go test -v
services:
  - redis
notify:
  email:
    recipients:
      - [email protected]
      - [email protected]
---
image: mischief/docker-golang
env:
  - GOPATH=/var/cache/drone
script:
  - go build
  - go test -v
services:
  - redis
notify:
  email:
    recipients:
      - [email protected]
      - [email protected]

Obviously, all the options could be different between the two docs, and it would probably be easier to implement a second build using the existing code rather than restructure into a matrix style.

from gitness.

@Linuturk I like that duplicating gives you more flexibility, but I feel 90% of use cases would just be duplicate configuration. For instance, if I wanted to run the build in 5 containers, I now have 5 portions of the YAML file where only the script section changes.

from gitness.

Maybe we have the secondary documents inherit all the values of the previous document, except the newly defined values in the secondary documents.

To be clear:

---
image: ubuntu
script:
  - go build
  - go test -v
services:
  - redis
notify:
  email:
    recipients:
      - [email protected]
      - [email protected]
---
image: rhel
notify:
  email:
    recipients:
      - [email protected]

from gitness.

@bradrydzewski, In your first comment, you stated:

Although I think we can draw some inspiration from Travis I do not want to just copy their approach as I think it would limit our capabilities. With Travis your build is heavily tied to a language:

language: go

When you specify a language with Travis, all that changes it the default build steps. The environment is more or less consistent across all builds.

from gitness.

For parallelization, could you just set the number of nodes you want to use and pass an environment variable into each and let the script deal with how to parallelize it? Use this config:

image: bmorton/ruby-2.1.2
nodes: 20
script:
  - bundle install
  - bundle exec rake ci
services:
  - postgres

And then each node gets run with the respective ENV vars passed in: DRONE_TOTAL_NODES=20 and DRONE_NODE=1.

From there, you'd just need a way to aggregate the results.

from gitness.

I like this idea, but each node would also need to be able to run a different script. My example wasn't clear on that. But one container might execute rspec tests and another might execute the jasmine tests, for example.

from gitness.

Yeah, I think for some people, there will be multiple build steps and you want those multiple steps parallelized. For others, you'll want to parallelize a single build step for test suites that take a long time to run serially.

from gitness.

Fair enough. That would work for my use case.

from gitness.

Maybe even something like this? This would allow you to outline different tasks you want run and if you want to run any given task on more than 1 node. Further, you could specify wait or depends_on_previous or something if you want the next task to wait for the previous task to complete.

image: bmorton/ruby-2.1.2
tasks:
  - nodes: 20
    script:
      - bundle install
      - bundle exec rake ci
  - wait: false
    script:
      - bundle install
      - ruby test/xunit/runner.rb
services:
  - postgres

from gitness.

Currently have a use case which I'd love to use Drone for, the fit and integration with Docker and GitHub are ideal, but being held up with the lack of multi environment builds.

Would love to see a feature like this sometime soon.

from gitness.

@beefsack can you provide some more details around your use case?

from gitness.

@bradrydzewski, currently building a CI system for Unreal Engine builds under different Linux distributions. There would multiple Docker images, one for each distribution with the relevant build dependencies installed, and I'd run the build commands inside each image to see which distributions successfully build.

Having Docker images is perfect for running under multiple distributions, and the GitHub integration is great because Unreal Engine is already on GitHub (behind a pay wall).

from gitness.

Thanks. This is definitely the goal, to be able to test a single commit against multiple Docker images. There are some pre-requisite features, namely #162 that we'll need to implement first. We'll also need to figure this out:

• How do the above use cases impact deployments?
• If we have 3 sub builds which one should be responsible for executing the deployment?
• If we have 1 sub builds responsible for deployment, should it wait for the other 2 to pass?
• How should this be represented in the yaml

from gitness.

@bradrydzewski, it makes most sense for those to be configurable I think, in my case the following would be ideal (but not necessary to my adoption):

• All builds trigger a separate deployment (compiled binaries for each target system are sent to a file server somewhere).
• Each build's deployment does not depend on other builds passing, even if it might mean some target systems won't have compiled binaries for a given commit.

from gitness.

Is the ability to specify multiple images available yet? Or, if not that, multiple YAML docs?

from gitness.

Any update on this? It's the only blocking issue for our company switching over to drone.io.

from gitness.

Also very keen on some kind of multi/sub-build capability. I have a number of build products I'd like to generate from one repo, and they are all quite different. Arguably the repo should just be split into components, but it would be very convenient if Drone supported multiple YAML files per repo. What if you could optionally specify the name of the .yml file to use when defining a build in the Drone web UI, and default to .drone.yml if none is given?

Alternatively, sub-build files could be declared in the YAML itself (apologies if this is invalid syntax):

builds:
  - drone/client.yml
  - drone/server.yml

Drone would execute the main .drone.yml, discover these sub-builds, then execute them after whatever else was in the main build file (possibly nothing). This could potentially be a recursive process if the sub-build YAML files also had builds sections.

Not too sure how this fits in with the matrix proposal. Perhaps the YAML could support both, and the matrix section, if present, would apply only to the .yml file it appeared in. Anyway, great work on Drone - it's a pleasure to work with so far!

from gitness.

Can I help with this or #162 ?

from gitness.

@kenberland yes, I replied on #162

from gitness.

hi partypeople! I totally want to see this in drone! Do you have an ETA on this? Whats the plan here? thanks!

from gitness.

👍 For an ETA

from gitness.

The plan is to get 0.3 released (and the exp branch merged into master) as soon as humanly possible. Once 0.3 is released I'd like to focus on matrix builds and pipelines, see #470 (comment)

This will be important because these two features will conflict. Matrix builds will complicate pipelines and vice versa. Both are really important and probably need to be architected in parallel.

from gitness.

great! let me know if I can help in any case. I'm not very familiar with go but probably there is other stuff to get this going fast.

from gitness.

Thought I should share my 2 cents:

Many of my build scripts spend the longest time setting up the environment. Drone + docker could easily circumvent that by letting the image be the matrix-like parameter:

image:
  - bjodah/trusty-python2
  - bjodah/trusty-python3

(EDIT:) or maybe something like:

matrix:
  - image=ubuntu:precise GCC_VERSION=4.6
  - image=ubuntu:precise GCC_VERSION=4.8
  - image=ubuntu:trusty GCC_VERSION=4.8
  - image=ubuntu:trusty GCC_VERSION=4.9

where image would be interpreted specially but GCC_VERSION is just an environment variable

from gitness.

For parallelization, could you just set the number of nodes you want to use and pass an environment variable into each and let the script deal with how to parallelize it? Use this config:

image: bmorton/ruby-2.1.2
nodes: 20
script:

• bundle install
• bundle exec rake ci
  services:
• postgres
  And then each node gets run with the respective ENV vars passed in: DRONE_TOTAL_NODES=20 and DRONE_NODE=1.

From there, you'd just need a way to aggregate the results.

This seems like a really nice idea, combined with something like https://github.com/ArturT/knapsack

from gitness.

We couldn't wait and rolled another solution. It's based on Integrity and leverages CoreOS for parallelism. We're elastically scaling workers into AWS to supplement the workers we have on site.

from gitness.

Did anybody step up to the plate yet? (Just asking to prevent duplicate work.) If not, I will put this on my plate round about 2 weeks from now (going for the matrix section style).

from gitness.

@drahnr thanks!

Just to clarify, are you referring to the matrix style referenced in #6 (comment) ? Because that is definitely the direction we want to go after speaking with some large open source projects and collecting feedback.

This change is going to be pretty involved and touch a lot of files, so it would be very helpful to break this up into smaller, focused pull requests (similar to what we are doing with #749) instead of one massive pull request. For example, the first pull request could modify the database, the second pull request could add rest endpoints, the third could modify the user interface, the fourth could alter the queue, etc ...

The first implementation of matrix builds doesn't need to be perfect, however, we need to be confident that it will (at some point) be able to address the following issues:

• which build (in the matrix) should handle the deployment / publish steps?
• should we publish / deploy only if all other builds in the matrix pass? If yes, how does this work?
• how does this work with the cache feature in the yaml? If multiple matrix builds are trying to access the cache it could lead to race conditions

from gitness.

Pretty much as comment #6 (comment) though I'd prefer the {{ var }} version since it is more recognizable, but that is just an implementation detail.

The idea was to run k (configurable) docker containers based on the matrix elements concurrently. When the matrix container queue gets empty, the results should be converged and if all builds succeeded, deployment is triggered (this will be the first implementation round, exceptions or allowed failure will be added later on).

I did not look into the caching features yet.

As said, I am currently pretty busy thus the delayed plating.

I will to split the changes up as far as it makes sense.

from gitness.

it would be awesome if you would provide the folks with information on this asap. we hardly wait for this and would be happy to test early stuff and provide feedback. 💖

from gitness.

Pretty much as comment #6 (comment) though I'd prefer the {{ var }} version since it is more recognizable, but that is just an implementation detail.

We ditched the {{ var }} syntax in the last release in favor of the $$ notation, so we would probably keep this for consistency.

When the matrix container queue gets empty, the results should be converged and if all builds succeeded, deployment is triggered

The implementation is going to be a bit tricky, but it is possible. The .drone.yml is converted into a shell script that gets injected into the container and executed. This script includes the build and test commands (ie the script section) and the publish and deployment commands. So basically it is one giant script.

This means we need to stop the container before the publish and deploy commands are executed. Then we need to re-start the container and skip directly to the publish and deploy commands.

When we first run the container we do something like docker run ./build.sh. When we restart the container (ie docker start) we cannot change the entrypoint command. This means the build script will be executed twice. It will need to know when to run the build and test commands vs the publish and deploy commands.

Perhaps something like this:

if [ -f /tmp/.skiptests ]  # checks to see if some file was written indicating our tests were executed
then

  # create some sort of file indicating we've run
  # our tests before.
  touch /tmp/.skiptests

  # my build and test commands here
  go build
  go test -v

else

  # my publish and deploy commands here
  git push heroku master

fi

Some of these changes may be contingent upon, or at least easier, when #749 is ready

I did not look into the caching features yet.

No worries, this is probably the easiest of the 3 to solve. I haven't put much thought into it myself, but we would likely have a cache for each axis in the matrix. It is the safest (and easiest) path forward and we can always fine tune the implementation in a follow-up release.

As said, I am currently pretty busy thus the delayed plating.

I completely understand. I'm happy to help when you're ready to start

I will to split the changes up as far as it makes sense.

When you're ready to start coding let's come up with a plan to chunk up the work.

from gitness.

$$var it is, didn't know about the drop of {{ var }} so far.

What means of inter-docker container communication can I take as granted? That is the most difficult point since this is what we will rely on to sync failed/successful tests back to the drone container/app before starting the publish and deploy iteration (got a bunch of ideas for that backpacked).

@benben
I will setup a testing repo for x86_64 Fedora 21, but be patient, that won't happen until the end of next week - at least.

from gitness.

This is a (barely) functioning proof of concept illustrating a matrix build from the Drone CLI:
https://github.com/drone/drone-cli/blob/matrix/runner/run/run.go

There isn't much to see, but wanted to post an update so that people could follow progress on this branch. The plan is to get matrix builds working from the command line utility first, and then integrating into Drone.

from gitness.

We are updating the .drone.yml file format and have a few different options described in #902

I would love to get some feedback on the existing proposals at the above link. The formats are un-related to matrix builds, however, it is a blocking prerequisite. I want to be sure we get it right. The quicker we get feedback the quicker we get matrix builds :)

from gitness.

i would like to be able to use

image:
  - ubuntu:14.04
  - ubuntu:12.04

instead of

image: ubuntu:$$ubuntu_version
[...]
matrix:
  ubuntu_version:
    - 14.04
    - 12.04

for just parallel builds. so we could use ubuntu and debian or centos if we don't use apt for example.

from gitness.

My use case comes down to building multiple variants of the same code using the very same image. Effectively this comes down to threading the configuration settings through whatever syntax you guys design:

1. Eg: invoking distinct scripts:

   matrix:
       debug: 
           script: ./scripts/ci-debug
       opt: 
           script: ./scripts/ci-opt
       opt-asan: 
           script: ./scripts/ci-opt-asan
   

2. Eg: setting environment variables:

   script: ./scripts/ci
   matrix:
       debug: VARIANT=debug
       opt: VARIANT=opt
       opt-asan: VARIANT=opt INSTRUMENTATION=asan
   

It would also be nice to keep track of the individual rows within the matrix. Eg: the "opt" variant may start failing.

from gitness.

@davidak there are no restrictions as to how or where matrix parameters get injected into the yaml file. You could test multiple distros by doing something like this:

image: $$docker_image
[...]
matrix:
  docker_image:
    - ubuntu:14.04
    - ubunut:12.04
    - centos:latest
    - debian:wheezy

The ability to inject parameters with $$ is quite flexible

from gitness.

from gitness.

quick screencast of Drone running matrix builds from the command line: https://twitter.com/droneio/status/577496429242912769

from gitness.

@bradrydzewski that's great to see, great work!

from gitness.

Any update on when this is going to land?

from gitness.

yes, I expect to have a working 0.4 distribution available around May 22nd (sourced from the bolt branch). It will then take between 2 and 4 weeks before it is merged into master, depending on how quickly we are able to test, fix bugs, backport existing plugins to the new plugin model, document changes, etc.

from gitness.

@bradrydzewski Will this pull request also allow for dependant builds (i.e. project b should be built after project a)? I think this is a bit different than a matrix build if I understand correctly.

from gitness.

@stevenpall we are launching a new plugin model (included with the matrix feature) that would allow you to augment builds. I think this dependant builds could probably be added as a plugin.

from gitness.

+1 Refreshing approach to the build matrix. It's nice to see that they can be include in the configuration file and injected into the build environment.

from gitness.

@bradrydzewski, any plans (dates) for release of this feature ?

from gitness.

@romani the 0.4 branch includes matrix builds, but it is still a bit too unstable and undocumented for people to start using. The 0.4 release, however, is still planned for this month

from gitness.

👍

from gitness.

+1

from gitness.

just wanted to give a quick update here.... I gave an implementation overview and live demo in last week's Rancher meetup of upcoming matrix build functionality. Link to the youtube recording:
https://youtu.be/86u8pVESbPQ?t=4586

from gitness.

WOW. This looks pretty cool (not only the matrix build, everything). Can't wait for the release :)

from gitness.

@bradrydzewski I haven't had the chance to watch the video but is there a doc specifying a build env/commands to build and try 0.4? Once I get that far I'll be able to help as much as possible but figuring it out on my own is too much time for me.

from gitness.

@mjschultz as far as I know the only documentation is in this issue

from gitness.

Merged into master. Note that this is the initial implementation of matrix builds. Now everyone can start following the open issue for parallal matrix builds (#1254) targeted for the 0.4.1 release 😄

You can find the matrix documentation here:
http://readme.drone.io/usage/matrix/

Enjoy!

from gitness.