Provide an easy way to mock the version of Backdrop core in PR sandboxes, without merging the changes

[klonos]

This comes up from time to time: less technical contributors that want to easily test changes prefer to test in our Tugboat PR sandboxes. Currently, we have no way to test things if the PR involves core upgrades that require an older version of core. Each time this comes up, I personally change the number in the BACKDROP_VERSION constant in bootstrap.inc. I do that on my local, and then either skip committing the change, or I do commit it and make a note for the core committer that will merge the PR to remove the change. This is not ideal, and has the risk of accidentally committing the change if the person that merges the PR forgets about it.

I thought that we could provide a way to mock the core version, and make it easy for people to be able to test these scenarios without having to set up the PR on their locals and have to apply patches etc. I have done some research, but not set on any specific method as the most appropriate, however, these options (or a combination of them) seem possible:

• take advantage of the environment variables that Tugboat provides, in order to detect if the Backdrop instance is running within a Tugboat sandbox or not: https://docs.tugboatqa.com/reference/environment-variables
• add a file similar to https://github.com/backdrop/backdrop/blob/1.x/.tugboat/settings.local.php (which is used in order to apply specific config overrides to the Tugboat sandboxes - see https://github.com/backdrop/backdrop/blob/1.x/.tugboat/config.yml#L16)
• use the special keyword merge=ours for a specific file in our .gitattributes file, which causes the file specified to be skipped/excluded when merging. See: https://stackoverflow.com/a/4520363/17665571

[izmeez]

If it can be done with the second approach using settings.local.php that would be nice. It was the first thought that came to mind as a method in keeping with how Backdrop does these things.

[docwilmot]

I'm not understanding the feature request here

[avpaderno]

I am not sure which benefit testing a PR with an older Backdrop core release would take. It does not seem something necessary to develop Backdrop core.

[izmeez]

I'm not sure going down this rabbit hole is worthwhile.

[klonos]

It does not seem something necessary to develop Backdrop core.

It is not meant to help with developing code - it's meant to allow more people to easily test things in PR sandboxes that would otherwise require them to set up an environment on their local, and apply patches (which is usually a task that requires more technical/developer aptness).

This request here was triggered by various issues I have worked on where in order to test things you are required to be running an older version of Backdrop core (which is impossible with our PR sandboxes, as they are always running the latest 1.x). The last issue where this happened was #5085, but there have been many occasions in the past.

[avpaderno]

Any issue like #5085 aims to change the current code, not any previous release. If somebody needs to test a patch in a previous Backdrop release used on a site, that can only be done on local.
IMO, it is not a task that should be simplified by changing the way preview sites are created for PRs. For those cases, I would not see as appropriate to create a PR just to have a preview site to test.

[avpaderno]

For that, it would probably be more appropriate to have a site like https://simplytest.me/, which allows to create a site running on any Drupal release, to which any module is added, and patches are added to the selected project. (Truly, creating a Drupal 8 site ends up with a build error; a site running on any Drupal release is not completely true.)