Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependent builds #249

Closed
dkubb opened this issue Sep 7, 2011 · 23 comments
Closed

Dependent builds #249

dkubb opened this issue Sep 7, 2011 · 23 comments

Comments

@dkubb
Copy link

@dkubb dkubb commented Sep 7, 2011

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
Copy link
Contributor

@parndt parndt commented Sep 7, 2011

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

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

@dkubb
Copy link
Author

@dkubb dkubb commented Sep 7, 2011

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
Copy link
Contributor

@joshk joshk commented Dec 19, 2011

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
Copy link
Member

@svenfuchs svenfuchs commented Feb 13, 2012

Changing the title to "Dependent builds"

@fd
Copy link

@fd fd commented May 31, 2012

Any news on this?

@letmaik
Copy link

@letmaik letmaik commented Nov 12, 2012

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
Copy link
Contributor

@sarahhodne sarahhodne commented Dec 14, 2012

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
Copy link
Member

@svenfuchs svenfuchs commented Dec 14, 2012

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
Copy link

@themihai themihai commented Dec 26, 2013

+1

@themihai
Copy link

@themihai themihai commented Dec 26, 2013

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
Copy link

@jbohren jbohren commented Dec 30, 2013

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
Copy link

@analytically analytically commented Mar 27, 2014

+1

1 similar comment
@lkrnac
Copy link

@lkrnac lkrnac commented Apr 14, 2014

+1

@kyab
Copy link

@kyab kyab commented May 20, 2014

+1

1 similar comment
@ioquatix
Copy link

@ioquatix ioquatix commented May 30, 2014

👍

@murrekatt
Copy link

@murrekatt murrekatt commented Jul 4, 2014

@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
Copy link

@jdmanton jdmanton commented Aug 4, 2014

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
Copy link

@adrianbk adrianbk commented Dec 21, 2014

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

@hugovk hugovk mentioned this issue Jan 1, 2015
3 of 3 tasks complete
@kbrock
Copy link

@kbrock kbrock commented Mar 3, 2015

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
Copy link

@nickmccurdy nickmccurdy commented Mar 7, 2015

👍 for dependent builds.

@doctorrustynelson
Copy link

@doctorrustynelson doctorrustynelson commented Mar 20, 2015

+1

@travis-ci travis-ci locked and limited conversation to collaborators Mar 20, 2015
@BanzaiMan
Copy link
Member

@BanzaiMan BanzaiMan commented Mar 20, 2015

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

@roidrage
Copy link
Contributor

@roidrage roidrage commented Jul 23, 2015

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.

@roidrage roidrage closed this Jul 23, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.