•  
      request #40460 Have a single source of truth for configuration variables
    Infos
    #40460
    Manuel Vacelet (vaceletm)
    2025-01-10 09:41
    2024-11-18 15:57
    42140
    Details
    Have a single source of truth for configuration variables

    As of today (16.1) the state of Tuleap config is messy. In order to get the list of all possible configuration variables, one must have rely on:

    • tuleap config-list for "recent" configuration variables, defined in sources and relying on #[ConfigKey] annotation
    • *.inc.dist files (local.inc.dist and equivalent in plugins) that defines variables as well as default values (and sometime default values for variables defined in sources 🙃)

    We thought for longtime that we should do a clean transfer for *.inc.dist (move to the appropriate class, replace all string usage by const usage, etc) but the result is that this work is just too much of a burden to be done so... it's not done.

    There is enough value to transfer everything in a dummy classes "as is" just to centralize the definition. Improvements might come later on.

    Scope:

    • Transfer configuration variables to code (instead of .inc.dist files)
    • Advertise where configuration variables should be set (DB or files)
    Site admin
    Empty
    Empty
    • [ ] enhancement
    • [x] internal improvement
    Empty
    Stage
    Manuel Vacelet (vaceletm)
    Closed
    2025-01-10
    Attachments
    Empty
    References

    Follow-ups

    User avatar

    Actually this cannot work as advertise because of the way variables are loaded in the plugin.

    To sum-up:

    • We can deal with default values set with constants in plugins, the mechanism exists and works well
    • We can deal with variables defined in DB for plugins, it's a bit of a hack but it works.

    However, we cannot have variables advertise with constants (via ForgeConfig load mechanism) whose values are set in plugin config files (/etc/tuleap/plugins/X/etc/X.config) because ForgeConfig is unaware of those files. It would require to modify the loading (hence the caching) mechanism. That doesn't seem to be the right move given that we want to align the the variables in DB via config-set.

    The work done on core will stay as is. For each plugin that still have configuration in files, I will create a dedicated request to have a proper transfer to the database.


    • Status changed from Under implementation to Closed
    • Connected artifacts
    • Close date set to 2025-01-10
    User avatar

    Remove the part about setting variables, it will not be part of this request.


    • Original Submission
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes
    User avatar
    • Original Submission
      Something went wrong, the follow up content couldn't be loaded
      Only formatting have been changed, you should switch to markup to see the changes