Bug 1486346 - "mbs-build local" fails with traceback, because it can not find some random file in /tmp
Summary: "mbs-build local" fails with traceback, because it can not find some random f...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: module-build-service
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Ralph Bean
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-29 14:07 UTC by Tomáš Hozza
Modified: 2017-10-03 19:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-03 19:36:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Tomáš Hozza 2017-08-29 14:07:15 UTC
Description of problem:
mbs-build fails with traceback, when I'm trying to locally build a module. I'm running "mbs-build local" in a directory, that contains modulemd file with the same name as the name of CWD.

Version-Release number of selected component (if applicable):
module-build-service-1.3.24-3.fc25.noarch

How reproducible:
always

Steps to Reproduce:
1. just run "mbs-build local" in a directory containing modulemd file

Actual results:
thozza@thozza-pc ~/devel/projects/modularity/bind (master %=)
$ ls
bind.yaml  LICENSE  README.md
thozza@thozza-pc ~/devel/projects/modularity/bind (master %=)
$ mbs-build local
INFO: You have not provided SCM URL or branch. Trying to get it from current working directory
INFO: Starting local build of file:///home/thozza/devel/projects/modularity/bind, branch master
2017-08-29 16:00:26,782 - MainThread - module_build_service - DEBUG - Setting topics: *
2017-08-29 16:00:26,894 - MainThread - module_build_service - DEBUG - Verifying modulemd
2017-08-29 16:00:26,899 - MainThread - module_build_service - DEBUG - Getting/verifying commit hash for file:///home/thozza/devel/projects/modularity/bind
Traceback (most recent call last):
  File "/usr/bin/mbs-manager", line 9, in <module>
    load_entry_point('module-build-service==1.3.24', 'console_scripts', 'mbs-manager')()
  File "/usr/lib/python2.7/site-packages/module_build_service/manage.py", line 316, in manager_wrapper
    manager.run()
  File "/usr/lib/python2.7/site-packages/flask_script/__init__.py", line 412, in run
    result = self.handle(sys.argv[0], sys.argv[1:])
  File "/usr/lib/python2.7/site-packages/flask_script/__init__.py", line 383, in handle
    res = handle(*args, **config)
  File "/usr/lib/python2.7/site-packages/flask_script/commands.py", line 216, in __call__
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/module_build_service/manage.py", line 153, in build_module_locally
    skiptests=skiptests)
  File "/usr/lib/python2.7/site-packages/module_build_service/utils.py", line 733, in submit_module_build_from_scm
    mmd, scm, yaml = _fetch_mmd(url, branch, allow_local_url)
  File "/usr/lib/python2.7/site-packages/module_build_service/utils.py", line 431, in _fetch_mmd
    with open(cofn, "r") as mmdfile:
IOError: [Errno 2] No such file or directory: '/tmp/tmpZ_dNLL/bind/bind.yaml'


Expected results:
It should work :)

Additional info:

Comment 1 Tomáš Hozza 2017-08-29 14:16:19 UTC
I tried module-build-service-1.3.26-3.fc25.noarch from updates-testing, but the issue is still present...

thozza@thozza-pc ~/devel/projects/modularity/bind (master %=)
$ mbs-build local
2017-08-29 16:14:06,408 - MainThread - module_build_service - DEBUG - Setting topics: *
2017-08-29 16:14:06,549 - MainThread - module_build_service - DEBUG - Verifying modulemd
2017-08-29 16:14:06,550 - MainThread - module_build_service - DEBUG - Getting/verifying commit hash for file:///home/thozza/devel/projects/modularity/bind
Traceback (most recent call last):
  File "/usr/bin/mbs-manager", line 9, in <module>
    load_entry_point('module-build-service==1.3.26', 'console_scripts', 'mbs-manager')()
  File "/usr/lib/python2.7/site-packages/module_build_service/manage.py", line 311, in manager_wrapper
    manager.run()
  File "/usr/lib/python2.7/site-packages/flask_script/__init__.py", line 412, in run
    result = self.handle(sys.argv[0], sys.argv[1:])
  File "/usr/lib/python2.7/site-packages/flask_script/__init__.py", line 383, in handle
    res = handle(*args, **config)
  File "/usr/lib/python2.7/site-packages/flask_script/commands.py", line 216, in __call__
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/module_build_service/manage.py", line 148, in build_module_locally
    skiptests=skiptests)
  File "/usr/lib/python2.7/site-packages/module_build_service/utils.py", line 909, in submit_module_build_from_scm
    mmd, scm, yaml = _fetch_mmd(url, branch, allow_local_url)
  File "/usr/lib/python2.7/site-packages/module_build_service/utils.py", line 500, in _fetch_mmd
    cofn = scm.get_module_yaml()
  File "/usr/lib/python2.7/site-packages/module_build_service/scm.py", line 254, in get_module_yaml
    "module YAML file. Couldn't access: %s" % path_to_yaml)
module_build_service.errors.UnprocessableEntity: get_module_yaml: SCM repository doesn't seem to contain a module YAML file. Couldn't access: /tmp/tmp_FliQF/bind/bind.yaml

Comment 2 Jan Kaluža 2017-08-29 15:03:36 UTC
Is there bind.yaml in a directory you are running `mbs-build local` in?

Comment 3 Jan Kaluža 2017-08-29 15:03:54 UTC
And is bind directory git repo?

Comment 4 Filip Valder 2017-08-29 15:16:47 UTC
*** Bug 1486331 has been marked as a duplicate of this bug. ***

Comment 5 Tomáš Hozza 2017-08-29 15:28:35 UTC
(In reply to Jan Kaluža from comment #3)
> And is bind directory git repo?

Yes, it is.

Comment 6 Tomáš Hozza 2017-08-29 15:29:05 UTC
(In reply to Jan Kaluža from comment #2)
> Is there bind.yaml in a directory you are running `mbs-build local` in?

Yes, there is...

From Bug description:
thozza@thozza-pc ~/devel/projects/modularity/bind (master %=)
$ ls
bind.yaml  LICENSE  README.md

Comment 7 Filip Valder 2017-08-29 15:30:43 UTC
So, what's the content of /tmp/tmp_FliQF/bind/ directory, please? (If it even exists.)

Comment 8 Tomáš Hozza 2017-08-29 15:35:34 UTC
(In reply to Filip Valder from comment #7)
> So, what's the content of /tmp/tmp_FliQF/bind/ directory, please? (If it
> even exists.)

It doesn't exist at all. Even the /tmp/tmp_FliQF is missing...

Comment 9 Nils Philippsen 2017-08-31 08:17:35 UTC
Some thoughts:

- Is bind.yaml committed to source control? AIUI, the "mbs-build local" will clone the local repo and work from that.
- If this is the repo you used in bug #1486369, you've probably fallen victim of the rededication of github.com/modularity-modules -- these repos don't contain modules anymore, but information about their dependencies to actually work on the modules on src.fedoraproject.org/modules (i.e., dist-git).
- The temporary working tree is probably removed before the script exits. I don't know if there are cmdline options to prevent that.

Comment 10 Tomáš Hozza 2017-08-31 09:24:50 UTC
(In reply to Nils Philippsen from comment #9)
> Some thoughts:
> 
> - Is bind.yaml committed to source control? AIUI, the "mbs-build local" will
> clone the local repo and work from that.

It was not. it does not make much sense to require this. Why would I need to commit a Work-In-Progress into the repository if I'm doing a local build? None of the packaging tools (e.g. fedpkg) requires this.

Nevertheless, the build seems to be running, once I commit the modulemd file into the repository.

Note that this is really a very bad behavior. It can easily happen, that the engineer is modifying the modulemd file to fix some issue, but without committing it to the git (even if the work is not finished yet), the previous version of modulemd from git will be used.

> - If this is the repo you used in bug #1486369, you've probably fallen
> victim of the rededication of github.com/modularity-modules -- these repos
> don't contain modules anymore, but information about their dependencies to
> actually work on the modules on src.fedoraproject.org/modules (i.e.,
> dist-git).

bind.yml WAS present. I expect that the local build needs only the modulemd file which was present in the directory.

> - The temporary working tree is probably removed before the script exits. I
> don't know if there are cmdline options to prevent that.

There are no useful cli options. Unfortunately, the tools makes tons of assumptions without providing a way to override them.

Comment 11 Tomáš Hozza 2017-08-31 09:27:23 UTC
(In reply to Tomáš Hozza from comment #0)
> Actual results:
> thozza@thozza-pc ~/devel/projects/modularity/bind (master %=)
> $ ls
> bind.yaml  LICENSE  README.md

I know it is hard to see, but this is included in the bug description.

Comment 12 Ralph Bean 2017-10-03 19:36:20 UTC
I agree, this is super confusing.

Let's take discussion over here, please:  https://pagure.io/fm-orchestrator/issue/727


Note You need to log in before you can comment on or make changes to this bug.