#268 custom method seems to pick ppc64le builders even though fedora-latest-x86_64 requested
Closed 7 years ago Opened 7 years ago by praiskup.

Warning: Permanently added '172.25.93.234' (ECDSA) to the list of known hosts.
Running: /usr/bin/copr-rpmbuild --verbose --drop-resultdir --srpm --build-id 730475 --detached
Version: 0.17
Task:
{'build_id': 730475,
 'project_name': 'distgen-ci',
 'project_owner': 'praiskup',
 'source_json': {'builddeps': 'git',
                 'chroot': 'fedora-28-x86_64',
                 'hook_data': True,
                 'resultdir': 'rpm',
                 'script': '\n'
                           '#! /bin/sh -x\n'
                           '\n'
                           'set -e\n'
                           '\n'
                           'hook_payload=$(readlink -f "${HOOK_PAYLOAD-hook_payload}")\n'
                           '\n'
                           '# clone the helper scripts when needed, and add to PATH\n'
                           'test -d copr-ci-tooling \\\n'
                           '    || git clone --depth 1 https://github.com/praiskup/copr-ci-tooling.git\n'
                           'export PATH="$PWD/copr-ci-tooling:$PATH"\n'
                           '\n'
                           '# clone the tested project\n'
                           'git clone --recursive --depth 1 https://github.com/devexp-db/distgen.git\n'
                           'cd distgen\n'
                           '\n'
                           'github-checkout --hook-file "$hook_payload"\n'
                           'cd rpm\n'
                           '\n'
                           'set -- $(github-parse-webhook --hook "$hook_payload")\n'
                           '\n'
                           'make RELEASE="PR${2}_$(date +"%Y%m%d_%H%M%S")"\n'
                           '\n',
                 'tmp': 'tmpjqj6rndp'},
 'source_type': 9,
 'task_id': '730475'}

Running: unbuffer copr-sources-custom --workdir /workdir --mock-config /var/lib/copr-rpmbuild/results/tmprtwc_pkl/mock-config.cfg --script /var/lib/copr-rpmbuild/results/tmprtwc_pkl/script --builddeps git --hook-payload-file /var/lib/copr-rpmbuild/results/tmprtwc_pkl/hook_payload --resultdir rpm

cmd: ['unbuffer', 'copr-sources-custom', '--workdir', '/workdir', '--mock-config', '/var/lib/copr-rpmbuild/results/tmprtwc_pkl/mock-config.cfg', '--script', '/var/lib/copr-rpmbuild/results/tmprtwc_pkl/script', '--builddeps', 'git', '--hook-payload-file', '/var/lib/copr-rpmbuild/results/tmprtwc_pkl/hook_payload', '--resultdir', 'rpm']
cwd: .
rc: 1
stdout: INFO:__main__:Working in '/workdir'
INFO:__main__:Results should be created in '/workdir/rpm'
INFO:__main__:running command: mock -r /var/lib/copr-rpmbuild/results/tmprtwc_pkl/mock-config.cfg --init
ERROR: Cannot build target x86_64 on arch ppc64le, because it is not listed in legal_host_arches ('x86_64',)
Traceback (most recent call last):
  File "/usr/bin/copr-sources-custom", line 77, in <module>
    run_cmd(mock + ['--init'])
  File "/usr/bin/copr-sources-custom", line 57, in run_cmd
    return subprocess.check_call(command, **kwargs)
  File "/usr/lib64/python3.6/subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['mock', '-r', '/var/lib/copr-rpmbuild/results/tmprtwc_pkl/mock-config.cfg', '--init']' returned non-zero exit status 6.
stderr: 

ERROR: Cannot build target x86_64 on arch ppc64le, because it is not listed in legal_host_arches ('x86_64',) in particular

Ye, well, normally for srpm builds any machine is good. With the custom method a user have a choice of a chroot. Frontend will need to parse source_json structure for the custom type and request builder of a particular architecture for the srpm build.

Metadata Update from @praiskup:
- Issue assigned to praiskup

7 years ago

Metadata Update from @praiskup:
- Assignee reset

7 years ago

After closing #274, @clime promised to have a look at this.

You can check: https://pagure.io/copr/copr/c/b9938dadf28b77ea7b540d4d8bed0199534a86a4?branch=master

I will give it some more testing and deploy as hotfix if it passes.

if str(self.task_id) == str(self.build_id)

This looks really ugly (overloaded semantics of task_id value).

I will give it some more testing and deploy as hotfix if it passes.

Thank you!

Btw. this would be enough: + "chroot": self.task.source_json_dict.get('chroot')
I remember that you bellowed that I don't speak Python when I did something similar, going through PR would mean we can at least spot your hacks.

--- a/frontend/coprs_frontend/coprs/views/backend_ns/backend_general.py
+++ b/frontend/coprs_frontend/coprs/views/backend_ns/backend_general.py
@@ -143,6 +143,11 @@ def get_srpm_build_record(task):
     if not task:
         return None

+    if task.source_type_text == "custom":
+        chroot = task.source_json_dict['chroot']
+    else:
+        chroot = None
+
     try:
         build_record = {
             "task_id": task.task_id,
@@ -151,6 +156,7 @@ def get_srpm_build_record(task):
             "project_name": task.copr.name,
             "source_type": task.source_type,
             "source_json": task.source_json,
+            "chroot": chroot,
         }

     except Exception as er

Btw. this would be enough: + "chroot": self.task.source_json_dict.get('chroot')

No, this is not correct (even though it would currently workd). chroot field in source_json is specific for custom method.

I remember that you bellowed that I don't speak Python when I did something similar, going through PR would mean we can at least spot your hacks.

Not getting what you mean. I would appreciate some 'thank you' for fixing a bug for the custom method.

if str(self.task_id) == str(self.build_id)

This looks really ugly (overloaded semantics of task_id value).

Slightly better would be to tell backend explicitly the type of the build (srpm vs rpm). Nevertheless, this is a good criterion as to recognize these two as well.

Sorry for my previous reaction: 'LOL' that I have deleted.

Metadata Update from @clime:
- Issue assigned to clime

7 years ago

Metadata Update from @clime:
- Issue status updated to: Closed (was: Open)

7 years ago

No, this is not correct

It's not. First, by the same logic I could tell that you shouldn't add
'chroot' field into the dict for non-custom method builds at all.

Since the current status suffers from rather lazily done design (it works, so
what.., but we are misusing the 'chroot' flag to indicate what VM the builder
should allocate), it's completely valid to consider that other methods could
(in future at least) request specific architecture, too. Btw. tito and
friend-methods are turing complete, too .. and then you might well face the
issues there, too -- eg if some command is not install-able on ppc64le.

Sooo, it would be completely correct to respect the 'chroot' regardless of the
chosen method (even though other methods don't use that now). It would be
actually much cleaner.

Not getting what you mean.

That's what expected.

I would appreciate some 'thank you'

You refused my PR offer (without review), but sincere thank you if you still
plan to hot-fix this in production, that would be awesome.

I would appreciate some 'thank you' for fixing a bug for the custom method.

Btw., I really feel more than "responsible" for fixing bugs there ;-).

Log in to comment on this ticket.

Metadata