-
Bug
-
Resolution: Fixed
-
Low
-
None
-
Severity 3 - Minor
-
Summary
SCM Caching (ref advertisements and upload-pack / cloning) can be configured in two different ways:
This results in inconsistent behaviour. Settings via the REST API are persistent, and write the configuration to the plugin_setting table. The persistent configuration appears to take precedence over any config set in bitbucket.properties - in other words, once the API is used to configure SCM caching, bitbucket.properties configuration ceases to have any effect one way or the other
Steps to Reproduce
- Set upload-pack caching to false in bitbucket.properties
- Confirm clones are no longer cached
- Set upload-pack caching to true via the REST API
Expected Results
???
Actual Results
bitbucket.properties configuration no longer has any effect
Additional considerations
In a Data Center cluster, when these configuration options are set via the REST API the value is propagated via Hazelcast to all nodes. However, when set via bitbucket.properties, if a node is restarted and picks up the configuration it is not propagated to other nodes. This results in inconsistent configuration within the cluster, where some nodes are behaving one way and other nodes a different way. I'm not sure if this is actually an unrelated hazelcast + bitbucket.properties configuration issue, or if it only applies to the cache settings described here.
Messaging and warning around this behaviour will be improved in the upcoming 5.0 release.
Note that the behaviour itself will not change, however it will be explicitly called out in the documentation for the properties.
Mismatches in the settings (ie. a property being set in the bitbucket.properties file and via REST) will be logged at startup or when a mismatch is created at runtime (by setting the configuration via REST).
This should help make it clearer when a property is overridden via REST and make this problem easier to spot should it occur.