The purpose of this page is to explain the process of adding new secrets and properties to Synapse.
Properties can be used to set flags and values that should change when building on a different machine. This allows local builds to interact with separate databases, worker queues, etc. from production and staging builds. This can also make local builds more lightweight (by setting certain features to only enable in production). Secrets provide similar benefits, but additionally restrict access to critical information such as credentials.
Accessing a default value to a property or secret via the Stack Configuration
The easiest way to set the default value of a property or secret is to add it to the stack.properties file.
The stack.properties file is tracked in Git, so don't commit any secrets to this file!
Once added to stack.properties, add a getter method to the StackConfiguration interface in lib/stackConfiguration and according implementation(s).
If the property is not a secret, the StackConfiguration implementation may simply use ConfigurationProperties.getProperty() to retrieve the property.
If the property is a secret, you should use ConfigurationProperties.getDecryptedProperty() to retrieve the property, as retrieved secrets will be encrypted.
Storing secret values
We use AWS Secrets Manager to store and retrieve secrets in production. Thus, secrets in production must be retrieved from the Secrets Manager. To add a secret to the Secret Manager, give an AWS administrator (currently Xavier Schildwachter) the property name and value (or how to generate or retrieve the value).
In most circumstances, developers should not have access to secrets, so you should rarely be able to directly give an administrator the secret.
Overriding a property or a secret from the command line
If you want to be able to override a property or secret from the command line (for example, to load properties in a remote build), then you have to modify the integration-tests/pom.xml file
Under the org.codehaus.cargo plugin, you must add a tag of the following form (these tags should already exist and you should merely have to add the leaf tag with your property name):
<configuration>
<!-- Container configuration -->
<container>
<systemProperties>
<org.sagebionetworks.my.property.name>${org.sagebionetworks.my.property.name}</org.sagebionetworks.my.property.name>
</systemProperties>
</container>
<configuration>
This property can now be set using the -D command line flag, for example:
mvn cargo:run -Dorg.sagebionetworks.my.property.name=myPropertyValue
Note that if your value has spaces, you must wrap the entire -D flag in double quotes:
mvn cargo:run "-Dorg.sagebionetworks.my.property.name=my property value"
Adding a property to automated builds
If you want your property to be set on Jenkins, in addition to the above, add a line to docker_build.sh:
bash -c "mvn clean ${MVN_GOAL} \
# ... other properties
-Dorg.sagebionetworks.my.property.name=${org_sagebionetworks_my_property_name} \
# ... other properties
And configure the build on Jenkins to export the property value into org_sagebionetworks_my_property_name:
export user=pUser
export org_sagebionetworks_stack_iam_id=<id>
export org_sagebionetworks_stack_iam_key=<key>
export org_sagebionetworks_stackEncryptionKey=<key>
export rds_password=<pwd>
export github_token=<token>
export org_sagebionetworks_my_property_name=myValueForAutomatedBuilds
# other properties may be listed...
/var/lib/jenkins/workspace/${JOB_NAME}/jenkins_build.sh