buildinspace / peru / 419
88%

DEFAULT BRANCH: master
Ran
Jobs 3
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
419

push

travis-ci

oconnor663 
add the --no-cache flag

We have some choices about how we define this. To be clear, "cache"
refers to two things at once:

1) The tree cache, a headless git repo. All of peru's file operations
are done by git running in this repo, so there's no sense in which we
could disable it.
2) The keyval store that lives next to the tree cache. This stores the
tree hashes that were last computed for modules, rules, and intermediate
operations like merges. This is what we can disable.

One option would be for --no-cache to disable the keyval entirely, for
example by replacing it with a throwaway dictionary. This would have the
result we want, but it's unnecessarily aggressive. For example, rules
are deterministic and cached based on the hash of their input. If we've
already computed "export: foo" for tree 4b825dc..., there's no reason to
compute it again. Same goes for the merge of all your import trees.

Instead, only skip reading the keyval in module.py. This means that git
repos will be refetched, curl modules will be redownloaded, etc., which
is exactly what we want. But we won't have to do unnecessary work.

Note that we don't do anything special to prevent plugin caching. So for
example, the git plugin won't reclone repos from scratch, and with exact
revs it might not even do a fetch. This won't affect the final result,
and again there's no reason force it to do unnecessary work. We could
probably be more explicit about this plugin contract in the docs.

The last consideration is whether we should also disable *writes* to the
keyval in module.py. I don't think we should, because it would be
confusing. For example, if you have a git module targeting master that
hasn't fetched for a while, and you run `peru sync --no-cache`, it's
going to get new commits. Now what happens if you then run `peru sync`?
Should the module *revert* back to the old files? I don't think that
makes sense, which means the no-cache sync still needs to write to the
keyval even though it doesn't read from it.

1464 of 1575 relevant lines covered (92.95%)

2.79 hits per line

Jobs
ID Job ID Ran Files Coverage
1 419.1 0
92.89
 Travis Job 419.1
2 419.2 0
92.89
 Travis Job 419.2
3 419.3 0
92.89
 Travis Job 419.3
Source Files on build 419
Detailed source file information is not available for this build.