--cache-builds will skip building even if a commit different to what's been built is locally available #1785
Comments
|
I think it would make sense to compare against the current 'subproject commit' value. That way we could also detect 'dirty' working trees as well and rebuild. (though with 'dirty' trees we would have to make sure that commit-dirty != commit-dirty). Non submodule usage still won't be able to detect changes to the working copy, not sure if we want to get into that game. It might do to just say "if you're not using submodules you shouldn't be touching the Checkouts folder" |
With or without this particular feature, I think that's a pretty reasonable guidance to give. |
|
I think Perhaps a PR can be opened to implement that? |
|
Why exactly should those be incompatible? |
|
While I think this feature eventually could/should support submodules, my concern is delaying the release for users than don't use submodules. I'd rather field the 80% solution now.
That being said, I could be overestimating the time needed to fix this, review, and accept it or underestimating the same for a PR that disables caching with |
|
I'd love to see a PR that does one of the following:
|
|
If you @mdiep or @BobElDevil can give some pointers towards the point 2 I am happy to give it a go:
|
|
Most of it should be contained in
|
We cannot use --use-submodules with --cache-builds, so dependencies do not become submodules. See Carthage/Carthage#1785
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
What's going on here |
The new --cache-builds behaviour is not behaving at least to my expectation if I use it together with
--use-submodulesfor a local package editing workflow. Here's a demonstration:carthage build --cache-builds Xwhere X is a package that's been pulled in with--use-submodulestoCarthage/Checkouts/X.Carthage/Checkouts/X.carthage build --cache-builds X– observe that X is skipped building and the commit from the local checkout was not read, presumably because the comparison is only done against the commitish in Cartfile.resolved.I would argue this is a bug, because
carthage buildwithout --cache-builds will in fact build the current revision fromCarthage/Checkouts/X. Requiring the editing of Cartfile.resolved as part of a local package editing workflow would be both illogical (leaks the implementation detail of what keys are used to invalidate the cache) and actually kind of dangerous because you may end up committing by accident for example changes toCartfile.resolvedthat have intentionally not been pushed out yet.carthage version: current head of master (9f1cc9e).xcodebuild -version: Xcode 8.2.1 (8C1002)--no-build? no--no-use-binaries? no--use-submodules? yesThe text was updated successfully, but these errors were encountered: