Store GraphQL v5 schema in silverstripe-cache folder

[GuySartorelli]

This has come up time and time again - most recently in https://github.com/silverstripe/silverstripe-graphql/issues/465

The main argument against it at the time was that we were very close to releasing the stable release of GraphQL v4 and we didn't want to poke the bear.

We now find ourselves in a situation where we're creating a new major release of this module, and we have the opportunity to reconsider what the default directory is for the graphql generated schema.

We've agreed internally that for CMS 5 the graphql schema should be included in the silverstripe-cache directory by default.

Acceptance criteria

• [x] By default, the graphql schema is stored where it currently is
• [x] If you set it to a blank string, it will go to the silverstripe-cache folder
• [x] Developers can override the location of the generated graphql schema by setting the SilverStripe\GraphQL\Schema\Storage\CodeGenerationStore.dirname configuration property (i.e. this config property still works as expected)
• [x] Schemas for multiple independent websites on the same server must not collide
• [ ] Test on on prod-like webservers, including multi-server environments where the temp folder may not be shared by the instances behind a load balancer
• [x] The CMS 5.1 changelog calls out that the location of this directory can be configured
• [x] The Silverstripe Cloud graphql documentation has accurate information for both CMS4 and CMS 5
• [x] This new set up is tested on SC and SCPS

Notes

• A proof of concept PR was made for this last year. It might be useful as a basis for this work - but don't add the warning messaging that PR included.
• This will be targeted at CMS 5.1
• Create a follow up card to explore possibility of updating the installer to use the new behaviour out of the box

PRs

• https://github.com/silverstripe/silverstripe-graphql/pull/534
• https://github.com/silverstripe/developer-docs/pull/257

[michalkleiner]

We are in feature freeze for CMS 5.0, right? Would this go against it if it was done for 5.0.0?

[michalkleiner]

If the overridden config still supports relative paths, then that will suffice for use cases where developers want to commit the generated files, but if it doesn't, we should still support the use case when the schema is generated e.g. by CI pipeline and deployed as part of the application.

[GuySartorelli]

We are in feature freeze for CMS 5.0, right? Would this go against it if it was done for 5.0.0?

My understanding is that we're in a "breaking API changes" freeze but new features are okay - but not 100% sure and the changelog section about it doesn't specify. @maxime-rainville what say you?

If the overridden config still supports relative paths

It will, don't worry. That config will work exactly the same way it currently does, with the exception that it's default value will be a blank string, and having it set to a blank string will result in storing in the cache dir.

[GuySartorelli]

For future people reading these comments: Max decided this didn't make the cut for CMS 5.0.0 but is worthwhile to add as an optional feature for 5.1.0

[GuySartorelli]

This has been moved to "awaiting" because we can't test in SC without deploying over what's currently there - and what's currently there is needed for an ongoing investigation about solr not working.

[michalkleiner]

Can you ask platform team to have an additional test environment added to the testing stack?

[GuySartorelli]

This has now been tested in cloud.

[emteknetnz]

Linked PRs have been merged and will be released in 5.1.0