#763 [frontend] allow us to create temporary aliases for chroots
Closed 2 years ago by praiskup. Opened 2 years ago by frostyx.
copr/ frostyx/copr os-release-alias  into  master

@@ -81,6 +81,12 @@ 

      # When the data in EOL chroots should be deleted (in days)



+     # We may have a (temporary) chroot that doesn't correspond with /etc/os-release

+     # on a client system, e.g. "rhelbeta-8" chroots in Copr which doesn't match to

+     # any real system, instead it is a temporary alias for "epel-8". In such case,

+     # set this to {"epel-8": "rhelbeta-8"}




  class ProductionConfig(Config):

      DEBUG = False

@@ -710,6 +710,7 @@ 



  def render_generate_repo_file(copr_dir, name_release):

+     name_release = app.config["CHROOT_NAME_RELEASE_ALIAS"].get(name_release, name_release)

      mock_chroot = coprs_logic.MockChrootsLogic.get_from_name(name_release, noarch=True).first()


      if not mock_chroot:

See #727 (comment-568671)
See BZ 1705912

This change will allow us to simply solve the BZ:1705912 by configuring
CHROOT_NAME_RELEASE_ALIAS to {"epel-8": "rhelbeta-8"}, which will
effectively redirect requests for "epel-8" repo to "rhelbeta-8" repo.

I'd appreciate an example confiugration (commented) here

rebased onto 95e9d62624d7e349af8d2cb19b7f220e6106ca5c

2 years ago

I'd appreciate an example confiugration (commented) here


Also, there was a question on a meeting, how the repofile is stored (filename). Well, like this


and the reponame is


so once the rhelbeta-8 in Copr gets changed to epel-8 and users re-enables the repositories, it will be stored in place of the original one. Is this a problem or actually the ideal possible outcome?

Is this a problem or actually the ideal possible outcome?

This sounds to be ideal to me :-), thank you, +1

rebased onto c765ab8

2 years ago

Merge doesn't work again (for at least the last 4 hours).

Pull-Request has been closed by praiskup

2 years ago