Same properties need different values.

[SolomonShorser-OICR]

Some "pre-slice" applications, such as GO Update depends on properties db.host, db.user, db.password, and db.name. These properties are also used by "relational database update" steps such as AddLinks. However, the "pre-slice" applications need these properties to refer to the main Curator database, and the "relational database update" steps need these same properties to refer to the local database that will be used to create the final Release database.
The result is that I'll probably need to correct the config file, reload it, and then change it again after the pre-slice steps have finished.

The current approach of putting everything into a single file is not working.

[cookersjs]

I don't recall this being an issue before... strange. Might be easiest to just change the required values in AddLinks? Really, the properties should be distinguished between curator/release DBs, but that's more of a future direction

[SolomonShorser-OICR]

Maybe something changed between the last release and this one in terms of how values are stored and propagated to the different steps, but it does not work.

I don't think making changes to the Java applications is the solution. Getting the correct values to the applications is the job of Jenkins.

[cookersjs]

I was just suggesting changing the configurations in AddLinks, since they are generic, not the code

[cookersjs]

PS - I'll unsubscribe myself from notifications once I've completed my documentation hand-off next week, sorry for interjecting

[SolomonShorser-OICR]

The code needs to read the configuration. But I don't think anything in those repositories (code or config) should need to change. I think this needs to be handled entirely in Jenkins.

[cookersjs]

Fair enough - then my Jenkins suggestion would be to create a 'DatabaseUpdatesConfig' file as a credential/secret, and then call that rather than 'ConfigFile' in the corresponding JFs