You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feels like it could be done by extending remote config to provide staging specific overrides, but may end up being repo-checker specific. The ring command (#848) will work in similar manor, storing staging specific information that is cleared on accept, but the intention was to use psuedometa data. The two concepts are not that different, but if remote config either the entire global whitelist from the target project will need to be included along with the staging specific entries or a method for appending to the global whitelist will be required.
It also may make sense to introduce a command line tool for setting the staging specific config to provide a simple workflow.
minimal requirements:
staging specific repo-checker-binary-whitelist* settings
clear staging specific values on accept of that staging
The text was updated successfully, but these errors were encountered:
Per mailing list discussion about how to handle ring packages whose install-time requirements are not in rings @DimStar77 requested to leave things as is and provide a way to keep a staging specific whitelist that is cleared on accept. This removes the need to whitelist problems, caused by stagings that have not been rebased, globally and instead can be restricted to individual stagings.
This feels like it could be done by extending remote config to provide staging specific overrides, but may end up being
repo-checker
specific. The ring command (#848) will work in similar manor, storing staging specific information that is cleared on accept, but the intention was to use psuedometa data. The two concepts are not that different, but if remote config either the entire global whitelist from the target project will need to be included along with the staging specific entries or a method for appending to the global whitelist will be required.It also may make sense to introduce a command line tool for setting the staging specific config to provide a simple workflow.
minimal requirements:
repo-checker-binary-whitelist*
settingsThe text was updated successfully, but these errors were encountered: