Merge pull request #18325 from bgruening/update_config_24.1

:Type: seq

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``object_store_templates_config_file``

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:Description:

    Configured Object Store templates configuration file.

    The value of this option will be resolved with respect to

    <config_dir>.

:Default: ``object_store_templates.yml``

:Type: str

~~~~~~~~~~~~~~~~~~~~~~~~~~

``object_store_templates``

~~~~~~~~~~~~~~~~~~~~~~~~~~

:Description:

    Configured Object Store templates embedded into Galaxy's config.

:Default: ``None``

:Type: seq

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``file_source_templates_config_file``

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:Description:

    Configured user file source templates configuration file.

    The value of this option will be resolved with respect to

    <config_dir>.

:Default: ``file_source_templates.yml``

:Type: str

~~~~~~~~~~~~~~~~~~~~~~~~~

``file_source_templates``

~~~~~~~~~~~~~~~~~~~~~~~~~

:Description:

    Configured user file source templates embedded into Galaxy's

    config.

:Default: ``None``

:Type: seq

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``user_config_templates_index_by``

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:Description:

    Configure URIs for user object stores to use either the object ID

    ('id') or UUIDs ('uuid'). Either is fine really, Galaxy doesn't

    typically expose database objects by 'id' but there isn't any

    obvious disadvantage to doing it in this case and it keeps user

    exposed URIs much smaller. The default of UUID feels a little more

    like a typical way to do this within Galaxy though. Do not change

    this value once user object stores have been created.

:Default: ``uuid``

:Type: str

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``user_config_templates_use_saved_configuration``

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:Description:

    User defined object stores and file sources are saved in the

    database with their last valid configuration. It may be the case

    that the admin changes file source and object store templates over

    time such that the variables and secrets an instance is saved with

    no longer match the configuration's expected values. For this

    reason, admins should always add new versions of templates instead

    of just changing them - however people take shortcuts and

    divergences might happen. If a template is changed in such a way

    it breaks or if a template disappears from the library of

    templates this parameter controls how and if the database version

    will be used.

    By default, it will simply be used as a 'fallback' if a

    configuration cannot be resolved against the template version in

    the configuration file. Using 'preferred' instead will mean the

    stored database version is always used. This ensures a greater

    degree of reproducibility without effort on the part of the admin

    but also means that small issues are not easy to fix. Using

    'never' instead will ensure the config templates are always only

    loaded from the template library files - this might make sense for

    admins who want to disable templates without worrying about the

    contents of the database.

:Default: ``fallback``

:Type: str

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

``enable_mulled_containers``

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    This requires the help_forum_api_url to be set.

:Default: ``false``

:Type: bool

  # FileSource plugins described embedded into Galaxy's config.

  #file_sources: null

  # Configured Object Store templates configuration file.

  # The value of this option will be resolved with respect to

  # <config_dir>.

  #object_store_templates_config_file: object_store_templates.yml

  # Configured Object Store templates embedded into Galaxy's config.

  #object_store_templates: null

  # Configured user file source templates configuration file.

  # The value of this option will be resolved with respect to

  # <config_dir>.

  #file_source_templates_config_file: file_source_templates.yml

  # Configured user file source templates embedded into Galaxy's config.

  #file_source_templates: null

  # Configure URIs for user object stores to use either the object ID

  # ('id') or UUIDs ('uuid'). Either is fine really, Galaxy doesn't

  # typically expose database objects by 'id' but there isn't any

  # obvious disadvantage to doing it in this case and it keeps user

  # exposed URIs much smaller. The default of UUID feels a little more

  # like a typical way to do this within Galaxy though. Do not change

  # this value once user object stores have been created.

  #user_config_templates_index_by: uuid

  # User defined object stores and file sources are saved in the

  # database with their last valid configuration. It may be the case

  # that the admin changes file source and object store templates over

  # time such that the variables and secrets an instance is saved with

  # no longer match the configuration's expected values. For this

  # reason, admins should always add new versions of templates instead

  # of just changing them - however people take shortcuts and

  # divergences might happen. If a template is changed in such a way it

  # breaks or if a template disappears from the library of templates

  # this parameter controls how and if the database version will be

  # used.

  # By default, it will simply be used as a 'fallback' if a

  # configuration cannot be resolved against the template version in the

  # configuration file. Using 'preferred' instead will mean the stored

  # database version is always used. This ensures a greater degree of

  # reproducibility without effort on the part of the admin but also

  # means that small issues are not easy to fix. Using 'never' instead

  # will ensure the config templates are always only loaded from the

  # template library files - this might make sense for admins who want

  # to disable templates without worrying about the contents of the

  # database.

  #user_config_templates_use_saved_configuration: fallback

  # Enable Galaxy to fetch containers registered with quay.io generated

  # from tool requirements resolved through Conda. These containers

  # (when available) have been generated using mulled -