Daemon vs --no-daemon

Help/Discuss
1

I am trying to execute a gradle script (gradle clean build-bundle) and my project has multi modules.
The script is supposed to generate few bundle files. It works fine for first time, but second and next iterations fail to generate these bundle files consistently. I see that one of the module (dependent) generates a fresh GUID with every single build, but another module which uses this dependent or common module keeps using the old GUID of the dependent module.

I dont see this problem if I dont use the daemon (–no-daemon). I thought it could be something related to cache, and I’ve deleted .gradle/caches content, but no change, I tried with --no-build-cache no luck.
I tried to delete the build folders and regenerate the data, still the same issue.

What am i missing? From where is it picking up the old GUID?

2

This sounds like custom logic that is in your build script, not something that is part of Gradle itself.

There’s not enough here to go on. We can’t debug custom code we’ve never seen.

3

I tried to upload some of my project files, but it says New users can’t upload.
jjustinic, can you tell me what information you are looking for?

4

There’s no need to upload files. It’s perfectly fine to post small snippets of code or links to a GitHub repo or Gist. The code that’s generating / consuming these GUIDs is going to be the most important, since that’s what you’re having issues with.

Paste relevant snippets between a start and end line with 3 backticks:

```
// code goes here
```
5

Thank you and ok, but how does daemon vs --no-daemon is changing this behavior?
So, I believe there is not much to suspect the plugin code that I am working on.

I am under an impression that this could be a gradle issue and hence using this Forum.

6

Using --daemon vs. --no-daemon determines whether or not multiple builds run in the same process or not. The incorrect use of a static variable will absolutely cause a problem here when using the daemon.

The only GUIDs that Gradle is creating though are very low level and if those are what you’re looking at, you’re not focusing on the right thing to actually diagnose your problem. Those related to the daemon will reflect differently depending on whether or not the same process executes multiple builds. If you’re looking at something higher level that could impact up-to-date checking, that’s being introduced by your build or plugins that it uses.

It’s impossible to provide you with any actionable advice without code and/or details about the tasks and how their execution is actually impacting the bundles though.