hey can we define schema in `debug` source sets and then con

Question

hey can we define schema in `debug` source sets and then consume it in `debug` directories only and have apollo generate debug only sources use case we want to include mock schema in our app without needing to introspect a local mock server but want to ensure it doesnt leak into production

agrosner · Answer

or in this case would we then need to use the ```apollo service service outputDirConnection connectToAndroidSourceSet demoDebug ```

Marco Pierucci · Answer

I m using per variant schema so per build type gotta be supported as well

agrosner · Answer

so we d need to utilize per variant schema here ie define one in release and one in debug

Marco Pierucci · Answer

agrosner · Answer

ah interesting so we d need to copy some portion of the schema over whether all or some

Marco Pierucci · Answer

You could have two completely different schemas or extend a common one depending on your needs

agrosner · Answer

~how do you extend a common one < Marco Pierucci> ~

agrosner · Answer

found it nvm

agrosner · Answer

`createAllAndroidVariantServices` seems to do the trick

mbonnin · Answer

`createAllAndroidVariantServices` does work Heads up it s running a different codegen instance for each of your variants

mbonnin · Answer

I was actually thinking about deprecating this one I m not sure there s a good use case for it

mbonnin · Answer

If your debug schema is a super set of your release schema i e it s a newer version you can do stuff like this ```apollo service release schemaFile set releaseSchemaFile srcDir operationFiles outputDirConnection connectToAndroidSourceSet release service debug schemaFile set debugSchemaFile Reuse the main source files srcDir operationFiles And add some debug only srcDir debugOnlyOperationFiles outputDirConnection connectToAndroidSourceSet debug ```

mbonnin · Answer

You could also have some release specific queries You just have to make sure there s no overlap or D8 will complain

agrosner · Answer

we also have another dimension of different services

agrosner · Answer

meaning we have multiple services so we d want api1Debug and api1Release for example

agrosner · Answer

what we want is ```src main graphql gt api1 gt schema graphqls operations graphl etc gt api2 src debug graphql gt api1 gt mock extra schema graphqls + schema graphqls operations graphql etc```

agrosner · Answer

with debug inheriting all of the stuff from api main including scalars etc but providing extra schema and `extend type` on main schema for development ahead of production inclusion

agrosner · Answer

how would we achieve extending it with mechanism you mentioned above

agrosner · Answer

or does not it not work this way

mbonnin · Answer

Processing sweat smile

mbonnin · Answer

gt with debug inheriting all of the stuff from api main including scalars etc but providing extra schema and `extend type` on main schema for development ahead of production inclusion Are your api1Debug and api1Release graphql files the same or are they different too

mbonnin · Answer

if you re using the same graphql files for debug and release it s going to simplify things quite a bunch

agrosner · Answer

we d want consuming modules to only need `src debug graphql` if theyre using any operations or fields defined from the `src debug graphql` of the schema module

agrosner · Answer

and the generated code to exist for those operations only debug source sets

mbonnin · Answer

Oh man mutlimodule as well

agrosner · Answer

but anything in `main` generated for both debug and release or just in normal output

mbonnin · Answer

multi module multi service multi variant sweat smile

agrosner · Answer

haha yeah our app no no joke laughing

agrosner · Answer

i think i have an idea ```api1 debugApi1 extends api1 releaseApi1 extends api1 api2``` all as service configurations where they inherit from base `api` or whatever

agrosner · Answer

and then connect the debug and release ones using the `outputDirConnection`

agrosner · Answer

and they share same scalars operations and schema in main schema but then can define add their own would that even work

mbonnin · Answer

TBH that s quite the setup

mbonnin · Answer

Defining custom scalars in child modules might not work

mbonnin · Answer

You need a central schema module that has access to all the type definitions

agrosner · Answer

yeah we re doing that 1 schema module with all scalars

agrosner · Answer

in reality we only need debug specific stuff so its not leaking into release builds but dont want to lose ability for shared fragments in our consuming modules that use debug only operations

mbonnin · Answer

gt our consuming modules that use debug only operations that use debug only fragments right

mbonnin · Answer

You can t reuse operations

agrosner · Answer

i think itll be ok if we connect the sources from the main service

agrosner · Answer

so we re developing new schema that is considered mock and not deployed to production we want to use existing types and reusable fragments from those existing types But we only want generation of those operations to exist in debug source sets

mbonnin · Answer

My canonical way to do this would be ``` schema build Gradle kts apollo service api1Release schemaFile set file src release graphql api1 schema graphqls srcDir src main graphql outputDirConnection connectToAndroidSourceSet release service api1Debug schemaFiles set files src release graphql api1 schema graphqls src debug graphql api1 extra graphqls srcDir src main graphql outputDirConnection connectToAndroidSourceSet debug Same for api2Release and api2Debug ```

mbonnin · Answer

But it s hard to tell without your complete setup this stuff is complicated

agrosner · Answer

ok ill try this and see if it can get it working and shoot back here with how I did it

agrosner · Answer

thank you for the help

mbonnin · Answer

Sure thing

agrosner · Answer

oh the file not found bug for apollo used coordinates surfaced ```build generated usedCoordinates apollo api1Debug usedCoordinates json No such file or directory ```

agrosner · Answer

i think its fixed by gradle syncing + some gradle plugin improvements ive made to our superplugin

agrosner · Answer

actually can repo now if I use configuration cache it looks for the file not found on used coordinates ill post the error here in a sec then if we need a ticket

agrosner · Answer

```FAILURE Build failed with an exception What went wrong Configuration cache state could not be cached field alwaysGenerateTypesMatching from type com apollographql apollo3 gradle internal ApolloGenerateSourcesTask error writing value of type org gradle api internal provider DefaultSetProperty gt java io FileNotFoundException graphql build generated usedCoordinates apollo api1Debug usedCoordinates json No such file or directory ```

agrosner · Answer

``` at okio Okio JvmOkioKt source JvmOkio kt 182 at okio Okio source Unknown Source at com apollographql apollo3 compiler ApolloUsedCoordinatesKt toUsedCoordinates ApolloUsedCoordinates kt 25 at com apollographql apollo3 gradle internal DefaultApolloExtension$registerCodeGenTask$1 invoke$lambda$15 DefaultApolloExtension kt 741 at org gradle api internal provider DefaultProvider calculateOwnValue DefaultProvider java 72 ```

mbonnin · Answer

What task name did you invoke for that Gradle run

agrosner · Answer

just trying to assemble our `app`

mbonnin · Answer

`assembleDebug`

agrosner · Answer

but it seems any invocation of `generateApolloSources` was doing it we have that run prior to using our wrapper tasks

agrosner · Answer

yeah

mbonnin · Answer

I would expect `assembleDebug` to run all the tasks so to populate the `usedCoordinates json` all the time Given that `Configuration cache state could not be cached` happens at the end of the build it s weird that the json is not there

agrosner · Answer

ill send a redacted log its the beginning of the build right after configure step completes

mbonnin · Answer

ahhhh

mbonnin · Answer

Makes sense at the end of the configuration step

mbonnin · Answer

not the end of the build

agrosner · Answer

redacted build log

agrosner · Answer

yeah we re using ``` add apollo$ service capitalized DebugUsedCoordinatesConsumer project add apollo$ service capitalized ReleaseUsedCoordinatesConsumer project ``` not the main `apolloUsedCoordinates` configurations

agrosner · Answer

removing debug release tags does not work ```org gradle api artifacts UnknownConfigurationException Configuration with name apolloApi1UsedCoordinatesConsumer not found ```

agrosner · Answer

happens even if i switch all modules to using both api services and `apolloUsedCoordinates` configuration as expected it still results in similiar configuration time error

mbonnin · Answer

This is on `3 7 4` right

mbonnin · Answer

It s a bit late for today but I ll try tomorrow see if I can reproduce

agrosner · Answer

yeah on 3 7 4

agrosner · Answer

no problem our services are also connected to sourceset variants ```service api1Debug srcDir src debug src main outputDirConnection connectToKotlinSourceSet debug api1Release ^ same as above except release api2Debug api2Release ```

agrosner · Answer

filed an issue to track <https github com apollographql apollo kotlin issues 4740|here>

mbonnin · Answer

Thanks