What @escapewindow said lastly there is as following:
We can put the regexes directly into bouncer_scriptworker/templates/script_config.json.erb, which means it's closer to developer -> json -> python regex. If there's another format that works better, e.g. yaml, we could switch script_config.json.erb to script_config.yml.erb. scriptworker::instance takes a $task_script_config argument that defaults to ${basedir}/script_config.json but can be any file path. In this example, it would be more developer -> yaml -> python regex
We can even create a python file in puppet, not a template. As long as we point to and use that file's regexes, it then becomes developer -> python regex, although we use puppet to deploy that python regex.
For the [now-obsolete] scriptworker docker sha allowlists, we had them in scriptworker.constants.DEFAULT_CONFIG, allowing for testing in unit tests. We also overrode them in puppet's config. And whenever we updated the puppet config, we also submitted a PR to update scriptworker.constants.DEFAULT_CONFIG to match.
downside: this means 2x as many PRs to deploy
upside: we can local unittest and end-to-end test
upside: when a new docker sha busted the trees, we could deploy the fix quickly via puppet, and were not required to deploy the scriptworker release immediately. The scriptworker patch could ride along with the next scheduled scriptworker release.
Having said that, I don't expect these bouncer regexes to change as often as the scriptworker docker shas did. I just want to point out that we still have options here.
Original conversation here.
What @escapewindow said lastly there is as following:
We can put the regexes directly into
bouncer_scriptworker/templates/script_config.json.erb, which means it's closer todeveloper -> json -> python regex. If there's another format that works better, e.g. yaml, we could switch script_config.json.erb to script_config.yml.erb.scriptworker::instancetakes a$task_script_configargument that defaults to${basedir}/script_config.jsonbut can be any file path. In this example, it would be moredeveloper -> yaml -> python regexdeveloper -> python regex, although we use puppet to deploy that python regex.For the [now-obsolete] scriptworker docker sha allowlists, we had them in
scriptworker.constants.DEFAULT_CONFIG, allowing for testing in unit tests. We also overrode them in puppet's config. And whenever we updated the puppet config, we also submitted a PR to updatescriptworker.constants.DEFAULT_CONFIGto match.Having said that, I don't expect these bouncer regexes to change as often as the scriptworker docker shas did. I just want to point out that we still have options here.