-
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.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|