• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

buildinspace / peru / 501 / 2
88%
master: 88%

Build:
DEFAULT BRANCH: master
Ran 24 Feb 2016 04:16PM UTC
Files 19
Run time 9s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

24 Feb 2016 03:56PM UTC coverage: 93.443% (+0.004%) from 93.439%
501.2

push

travis-ci

oconnor663
disable recursion by default, and update the warning

It turns out that recursion-by-default interacts poorly with one of
peru's core design goals, that it should be easy to call from other
cools. Consider this example:

1. Project A has some peru dependencies and a Makefile, so it runs
   `peru sync` inside the Makefile.
2. Project B has the same structure, and also B depends A. That means
   that B's peru.yaml file imports A, and also B's Makefile calls A's
   Makefile.
3. You clone Project B and run `make`.

The first thing that will happen is probably B's Makefile calling `peru
sync`. Now if recursion is on, that sync will *also* fetch A's files.
The next thing that happens might be B's Makefile calling into A's
Makefile, which is going to try to `peru sync` again. This is the
problem. A's dependencies are already in place, because of the recursive
sync, and when A tries to sync them again it's going to run into an
existing files conflict.

The core issue is that when peru is wrapped by other tools, it's not ok
to reach through those abstractions and aggressively sync stuff. We
could maybe come up with some fancy logic to detect when an outer
project has already synced us, to avoid the conflicts in this case, but
there are more complicated situations where that doesn't help. What if
the inner project decides to sync something *different*? What state
would that put the outer project in?

Instead of confronting this chaos, we're disabling recursive fetching by
default. It's still available to projects that want it, but it won't
screw up projects that don't expect it.

This is a breaking change, and we've introducing a warning about it in
c10c368. The next release that includes this commit should be 0.4.0.
We'll probably remove the warning in 0.5 or 1.0, whichever comes first.

See also https://github.com/buildinspace/peru/issues/146.

1596 of 1708 relevant lines covered (93.44%)

0.93 hits per line

Source Files on job 501.2
  • Tree
  • List 0
  • Changed 1
  • Source Changed 1
  • Coverage Changed 1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 501
  • Travis Job 501.2
  • 0f393d9e on github
  • Prev Job for on master (#500.2)
  • Next Job for on master (#502.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc