--cache-builds will skip building even if a commit different to what's been built is locally available #1785
Description
The new --cache-builds behaviour is not behaving at least to my expectation if I use it together with --use-submodules for a local package editing workflow. Here's a demonstration:
- Build your dependent package X:
carthage build --cache-builds Xwhere X is a package that's been pulled in with--use-submodulestoCarthage/Checkouts/X. - Make local changes to X and commit them to the submodule at
Carthage/Checkouts/X. - Repeat building 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 build without --cache-builds will in fact build the current revision from Carthage/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 to Cartfile.resolved that have intentionally not been pushed out yet.
carthage version: current head of master (9f1cc9e).xcodebuild -version: Xcode 8.2.1 (8C1002)- Are you using
--no-build? no - Are you using
--no-use-binaries? no - Are you using
--use-submodules? yes
Activity
BobElDevil commentedon Feb 23, 2017
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"
mz2 commentedon Feb 23, 2017
With or without this particular feature, I think that's a pretty reasonable guidance to give.
scottrhoyt commentedon Feb 23, 2017
I think
--use-cacheshould be incompatible with--use-submodulesfor the time being. The guidance should remain that modifying Checkouts without--use-submodulesresults in undefined behavior. What do you think about that?Perhaps a PR can be opened to implement that?
mz2 commentedon Feb 23, 2017
Why exactly should those be incompatible?
scottrhoyt commentedon Feb 23, 2017
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.
--use-submodulesusers won't have their current behavior changed. And since one of the major use cases for submodules is to change dependencies in step with a main project, the value of caching is lower than for normal users.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
--use-submodules.mdiep commentedon Feb 24, 2017
I'd love to see a PR that does one of the following:
--use-cachewhen--use-submodulesis specifiedmz2 commentedon Feb 24, 2017
If you @mdiep or @BobElDevil can give some pointers towards the point 2 I am happy to give it a go:
mdiep commentedon Feb 25, 2017
Most of it should be contained in
VersionFile.swift.git rev-parse HEADgets the current commit. That can be executed in a submodule to get the current commit for that submodule. I believe a Carthage wrapper forrev-parsealready exists.Install RxSwift and R.swift
stale commentedon Jun 30, 2018
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.
Feelmyvibes420 commentedon Oct 3, 2023
What's going on here