#1068 the %copr_username isn't defined on copr builders
Merged 7 months ago by frostyx. Opened 7 months ago by schlupov.
copr/ schlupov/copr define_copr_username  into  master

@@ -27,6 +27,8 @@ 

          self.resultdir = resultdir

          self.config = config

          self.logfile = self.config.get("main", "logfile")

+         self.copr_username = task.get("project_owner")

+         self.copr_projectname = task.get("project_name")

  

      def run(self):

          open(self.logfile, 'w').close() # truncate logfile

@@ -66,7 +68,8 @@ 

          template = jinja_env.get_template("mock.cfg.j2")

          return template.render(chroot=self.chroot, task_id=self.task_id, buildroot_pkgs=self.buildroot_pkgs,

                                 enable_net=self.enable_net, use_bootstrap_container=self.use_bootstrap_container,

-                                repos=self.repos, pkg_manager_conf=self.pkg_manager_conf)

+                                repos=self.repos, pkg_manager_conf=self.pkg_manager_conf,

+                                copr_username=self.copr_username, copr_projectname=self.copr_projectname)

  

      def produce_srpm(self, spec, sources, configdir, resultdir):

          cmd = MOCK_CALL + [

file modified
+2

@@ -14,6 +14,8 @@ 

  config_opts['use_host_resolv'] = False

  {% endif %}

  

+ config_opts['macros']['%copr_username'] = '{{ copr_username }}'

+ config_opts['macros']['%copr_projectname'] = '{{ copr_projectname }}'

  config_opts['use_bootstrap_container'] = {{ 'True' if use_bootstrap_container else 'False' }}

  

  {% if use_bootstrap_container %}

file modified
+4 -1

@@ -68,7 +68,8 @@ 

          # This is how mock itself does it

          def include(*args, **kwargs):

              pass

-         config_opts = {"yum.conf": []}

+ 

+         config_opts = {"macros": {"%copr_username": "@copr", "%copr_projectname": "copr-dev"}, "yum.conf": []}

          cfg = re.sub(r'include\((.*)\)', r'include(\g<1>, config_opts, True)', cfg)

          code = compile(cfg, "/tmp/foobar", 'exec')

          exec(code)

@@ -77,6 +78,8 @@ 

          self.assertEqual(config_opts["chroot_additional_packages"], "pkg1 pkg2 pkg3")

          self.assertEqual(config_opts["rpmbuild_networking"], True)

          self.assertEqual(config_opts["use_bootstrap_container"], False)

+         self.assertEqual(config_opts["macros"]["%copr_username"], "@copr")

+         self.assertEqual(config_opts["macros"]["%copr_projectname"], "copr-dev")

          self.assertEqual(config_opts["yum.conf"], [])

  

      @mock.patch("copr_rpmbuild.builders.mock.get_mock_uniqueext")

Fixes: #1037

Project_owner can be also a group.

This is compat thing; we used to define this before. But could you please also define %copr_owner (this better aligns with current copr code) and also %copr_project?

Or dunno, maybe %copr_project_owner and %copr_project_name.

Do you remember whether the %copr_username used to be in fact username or whether it was owner name? And also, would people care if the value changed to just username? I am asking because I am not sure whether you are suggesting to have the same value of %copr_username and %copr_ownername macros, or not.

See https://copr.fedorainfracloud.org/backend/get-build-task/1052939-fedora-30-i386
I now use project_owner value for the macro %copr_username so if I add %copr_project_owner it will both have the same value.

I don't remember :-/ it should be easy to find ... IOW so yes, I thought that both should have the same value... if they are present. OTOH, I am not 100% sure we have to keep the compatibility layer with something which doesn't work for year or two now; ... so perhaps we can only have two new macros, one for owner and second for project name?

As I understand it, people don't even care what the value is. They basically need a boolean value "Am I building in the Copr or nah?", i.e. they care whether the macro is defined. Right? If this is the case, I would create the new proposed macros, and set %copr_username to username (not group name). Maybe username of the submitter?

Submitter is not always known..., we only know owner and project name 100%. Otherwise I'm fine with what you propose.

rebased onto 15ab1edc6087012b2650bdbfcd9d17e20016984f

7 months ago

I added the %project_name macro and I left the %copr_username as it was. So now we have two macros for the owner and for the project name.

rebased onto 9c8d3354414ccf1af5e048566b7fe196f1d3e9ba

7 months ago

rebased onto 460eae6

7 months ago

Pull-Request has been merged by frostyx

7 months ago

I only miss the ownername.. that would better suit group vs. user projects.