Dependent builds

[dkubb]

An awesome feature to have would be a way to specify project dependencies (or better yet infer them from the Gemfile/gemspec), so that when a project builds successfully, all it's dependents' (that travis knows about) are built too.

This is a feature we use in the DataMapper CI, where anytime dm-core passes, it executes a build for every other dependent gem.

[parndt]

Sounds like a cool idea to ensure continual integration ;-)

How would we update those dependencies to reference the one we just built?

[dkubb]

I don't know if travis aims to be general purpose, or if it's going to be only ruby specific, so this approach may not apply. I'm also not sure if travis is coupled to bundler either, but if it is I think this might work.

I was thinking it might be possible to track the dependencies in each Gemfile.lock. When one of the dependencies' builds are successful, we go to each dependent, run the "bundle update" and if the Gemfile.lock changes we rebuild the gem.

In other words we leverage bundler to tell us when a gem's dependencies have changed rather than trying to do too much inside travis.

[joshk]

This is a cool feature which we nick named 'dependent builds'. The easiest and most reliable way to do this is to specify repos to test in the .travis.yml, but those repos would need to use the master version of the changed repo, if you know what I mean :)

We would love someone to help with this feature :)

[svenfuchs]

Changing the title to "Dependent builds"

[fd]

Any news on this?

[letmaik]

This is important for Maven projects in Java, too. But it applies only when a project depends on SNAPSHOT versions. For new release versions, a change in the pom must be done and committed which then triggers a build anyway.

[sarahhodne]

Which way should the specification go? "If this repository passes, build these other repos" or vice versa? The latter sounds more sensible to me.

However, if we go with that we need to store this information somehow, as we can't realistically go through every GitHub repo with a .travis.yml file checking if they depend on this build.

We could add a Dependency model that hooks up two repositories, but then we need to make sure that this stays in sync every time the configuration updates.

As @joshk said, we also need to figure out what version of the dependency is the "master". This could be as easy as specifying a branch together with the name of the repository when specifying dependencies, though.

If anyone else has any ideas on this, please do tell.

[svenfuchs]

I think the generalized idea here is some kind of "subscription" api. I.e. "one" (an app) can subscribe to events on builds. Now this app can hold the information that

• travis-core wants to trigger travis-api (case 1, here one's in control of dependencies)
• travis-api wants to be triggered when sinatra has built (case 2, not in control of sinatra)

... and in turn hit the travis-api to run a build.

We'd also want to consider how we allow to filter things and how we allow to parametrize the created build. E.g. it would be handy to be able to run a feature branch on travis-api when a feature branch on travis-core has passed.

my2c :)

[themihai]

+1

[themihai]

I would propose to add a git submodule detection so when a submodule is detected the build plan should start watching these repositories from submodules as well.
Simply said when any of the repositories loaded as submodules are updated the build plan should get triggered as well.
Another option would be to simply define the repositories you want to watch as dependencies on .travis.yml .

[jbohren]

Another option is to just make this part of the GitHub integration. Right now the service hooks let you specify a travis user/token/domain, but in addition there could be a "dependencies" list where a new build for that repo gets triggered if a specified branch of another specified repo builds and passes.

[analytically]

+1

[lkrnac]

+1

[kyab]

+1

[ioquatix]

👍

[murrekatt]

@themihai, submodules work differently. using a submodule you have already pinned the repo with that submodule to use a specific commit of the submodule. if you want to change this you would manually adjust that with e.g. git pull and then commit that. this will trigger a rebuild of the repo. hence, all good.

the "problem" comes when you don't control the version explicitly inside the repo, but rather rely on a mechanism outside like follow HEAD of another repo or e.g. a tag that is moved somewhere. in both these cases, the repo you want to rebuild doesn't know that a dependency changed unless it is told so.

one way to provide a generic solution to this would be to add an explicit list of github repos in the .travis.yml file. this could allow for e.g. automatic setup of webhooks or other triggers from those repos or using a subscription api to changes in those repos.

in any case, this is an important ci feature and needs to be repo content agnostic. it's a trigger from repo/branch to repo/branch. i.e. if .travis.yml would say it depends on a repo r and only branch b, changes to only that combination will trigger.

what would prevent this kind of setup for travis?

[jdmanton]

It doesn't solve this scenario, but this script solves the inverse problem, namely rebuilding projects dependent on a parent project that you own.

[adrianbk]

The following gradle plugin uses the travisci api to build dependant/child projects https://github.com/adrianbk/gradle-travisci-trigger-plugin

[kbrock]

This reminds me a little of automatic publishing github pages - the difference being that it would just trigger a build in another repo.

Would it be possible to leverage a technique like this?

[nickmccurdy]

👍 for dependent builds.

[doctorrustynelson]

+1

[BanzaiMan]

This is on our road map. If you want to be notified of progress when it happens, please subscribe, not 👍.

[roidrage]

Closing this issue for now, as we have no immediate plans to add this feature.

Should we add it to the roadmap eventually, we'll make sure to update this ticket.