Invalidate the build based on external dependency changes #967
Comments
nshahan
added
type-enhancement
|
Two possibilities I can think of:
Either of these would require new APIs. |
|
This is more a general issue with using external dependencies I think. Today if you are using any external executable and invoking it inside a scratch space we don't know if/when that external executable changes. In this case, its even more complicated because I believe the the dartanalyzer executable is actually just a shell script that runs the analyzer snapshot with the dart vm. We would need to track the dart vm itself, plus the snapshot and shell script. Computing hashes of some of these larger files would also likely be slow. We could also just invalidate builds whenever the dart sdk version changes (add that as an encoded field on the asset graph). This would solve things for analyzer/dartdevc but not other external executables. |
|
Could builders expose an optional class UsesDartSdkBuilder extends Builder {
// Used as part of the Builder digest?
@override
Future<List<String>> get externalDependencies async => [
_getDartSdkVersion(),
];
}Optionally, I'd like to see some sort of easily-consumable pattern for a builder that executes via IPC so others can write stuff using other external dependencies more easily, maybe that can simplify this? |
matanlurey
changed the title
matanlurey
added
the
P1
|
leaving this open, we do track dart sdk versions now but a more general purpose thing would be better |
|
After some discussion we think we could solve this by allowing you to configure an We could migrate our tools that are dependent on the SDK version to use this and be a bit more optimal than today. It would also satisfy both the environment check and build invalidation problems. |
|
Presumably we would not attempt the build if you |
|
I think we'd not attempt the build (or maybe attempt the rest of the build but mark the actions using that builder as failures without trying to run them) with either |
Interesting idea... we could also just require the user to disable the builder explicitly (but would need global config). My only real concern with either of those approaches is you may very well get a lot of cascading build failures from steps that try to read those files. |
|
Yeah the tradeoff is between the two sharp edge scenarios: "Why did you bother running this build when it's all going to fail" vs "Why can't I just run the build and get DDC output to test things even though this inconsequential other thing is going to fail" |
Any update on the API like this? I'm building a package that will generate source code for a dart file using the data from the |
|
Does this |
|
Yes, it does. But with #2851 it won't be a problem, right? |
|
That PR doesn't allow you to reach outside the package, it just allows you to expose files outside the |
|
Okay, I think I misunderstood the PR then. But may I know why does it matter? Because, as long as there is an API like the suggested one, I can still make a function using I just need a way to invalidate the snapshot once the specified asset has been modified. |
|
Right, if you use In an ideal world this would not mean deleting the entire build cache, as only a few actions are likely affected, and also ideally the user themselves wouldn't have to do something manually here. |
|
Okay, I think I see your point. If I could read the value of But is it possible to have a workaround for reading the |
|
There is not a real solution for what you want to do today, the closest thing would be using a symlink to the file in your package, but I don't think the file watcher would work so you would have to restart the build whenever that file changed, at which point we should see that it has been modified I think. Note that once the pull request you linked above is published you could move the file outside of One potential workaround although I have no idea if it would be possible for your use case, is to make the dependencies:
env:
path: /some/place/envAnd then you could construct an |
I ran into an issue where running build_runner build/serve was crashing due to an analyzer error (stack trace below). @jakemac53 correctly diagnosed this as a cached summary that needed to be rebuilt.
Is there some way that this can be detected and handled automatically? If not, can it be detected and given a better error message that doesn't include the message from dartdevc about a bug in the compiler?
The text was updated successfully, but these errors were encountered: