Sporadic error: "none of the consumable configurations have attributes"

I am seeing sporadic gradle build error - I am not able to reproduce it locally on mac or windows machine it only happens in build pipeline - pipeline has retry built into it but it is not effective, if it fails once it fails again on all retries - it succeeds on new run (new agent built from scratch)

using gradle 7.6.2

any idea how to debug this error further? - or what on the build system can be cleaned such that build succeeds on immediate retry - tried removing .gradle folder, clean build, stopping gradle daemon - none of it helped.

project is complex and has many different dependencies, this error is seen for many different libraries, in sample below it happened for react-native-permissions:

Could not determine the dependencies of task ':app:compilePowerAppsDebugJavaWithJavac'.
> Could not resolve all task dependencies for configuration ':app:powerAppsDebugCompileClasspath'.
> Could not resolve project :react-native-permissions.
  Required by:
      project :app
> No matching configuration of project :react-native-permissions was found. The consumer was configured to find an API of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'debug', attribute 'com.android.build.api.attributes.ProductFlavor:playerFlavor' with value 'powerApps', attribute 'com.android.build.api.attributes.ProductFlavor:react-native-camera' with value 'general', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.3.1' but:
       - None of the consumable configurations have attributes.

If you can, enable build --scans so that you have one from success and from from failure to compare.

Other than that, it might make more sense to ask react-native-permissions maintainers about problems with their build. :slight_smile:

same thing is happening with many other libraries in the project, so I don’t think whoever maintains react-native-permissions would be able to help.

I have scans when the issue happened with different library with the same error message.

failed build:

succeeded build:

conditions for these two runs are identical - why would one succeed and other fail?

Hm, the build scans are not too enlightening for me.
As far as I understood how it works is, that you use npm to install those dependencies which then are actual gradle builds which you then include in your actual project.
I can just suspect that somehow the npm-installation did not work properly or something like that.
One would probably have to investigate the failing build itself to see what is going on.

From what I can see from the build scan, I would say work/1/s/src/Devices/Player/node_modules/react-native-powerapps-webview/android is missing or the files in there are not proper. The plugins section says that in the successful build react-native-powerapps-webview has the AGP applied, while in the failed one it has not.

1 Like

Thanks a lot Bjorn! - your guess was spot on - we run post npm installation script to remove jcenter references from build.gradle files, due to a bug in script we ended up with empty build.gradle files sporadically resulting in this build failure.

it would be great if gradle would validate build.gradle file and fail with ‘invalid configuration’ rather than ‘none of the consumable configurations have attributes’

First things first, it’s Björn or Bjoern, not Bjorn. :wink:

your guess was spot on

It was not so much a guess, the build scan says that the Android plugin was not applied in that project. :smiley:

it would be great if gradle would validate build.gradle file and fail with ‘invalid configuration’ rather than ‘none of the consumable configurations have attributes’

It does.
An empty build script is perfectly valid.
Even an absent build script would be perfectly valid.
It just then has the defaults or configuration injected from outside the build script (which is bad-practice and discouraged though).
So there is really nothing more Gradle could do to help you.
The error is exactly describing the situation.
You depend on that project, but there are not configurations defined as you emptied the build script.