buildinspace / peru / 232
88%

DEFAULT BRANCH: master
Ran
Jobs 2
Files 16
Run time 16s
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
232

push

travis-ci

oconnor663 
remove the 'build' command

Summary:
`peru build` was an interesting idea, but the more we think about what it will
need to support, the more it looks like it'll require a lot of complexity
without a lot of benefit. Peru doesn't get in the way of source control because
it doesn't have to know anything about it. That's a good design decision.
`peru build` feels like the opposite, like peru needs to know all about your
build system. That looks more and more like a mistake.

`peru sync` has the nice property that it involves very little state. You're
either synced, or you aren't. You don't need to worry about *which*
dependencies you've synced, etc. Build commands, on the other hand, tend to
have a lot of state. You might want to build particular targets (`make debug`
vs `make release`) or pass any number of options to the build system
(`make -j 8`). We really don't want to wrap all this functionality, because
we'll inevitably do a crap job of it and just end up making it harder to use
your tools.

This diff gets rid of the build command entirely. For projects that want to
sync and build, the preferred approach will be to have the build scripts call
peru, rather than having peru call the build scripts. The 'build' field at the
top level will no longer have any meaning until we introduce recursive
projects. (The same was always true of 'export' and 'files', so if anything
this is more consistent.)

We'll need to think a little more about how things should work in recursive
projects. For example, if a build tool in a module calls peru again, should
that Just Work? Or should peru be aware that it's running recursively and
behave differently? Thoughts for the future.

Test Plan:
The build command integration test included some important cases of
rule chaining in local modules. Move those to a new overrides test.

Reviewers: sean

Differential Revision: https://phabricator.buildinspace.com/D64

821 of 883 relevant lines covered (92.98%)

1.86 hits per line

Jobs
ID Job ID Ran Files Coverage
1 232.1 0
92.87
 Travis Job 232.1
2 232.2 0
92.98
 Travis Job 232.2
Source Files on build 232
Detailed source file information is not available for this build.