according to modulemd/specs.yaml the whole components part of a module description file is optional. Leaving that out results in a traceback:
2016-09-06 12:30:02,092 - rida - ERROR - Exception on /rida/module-builds/ [POST] Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app response = self.full_dispatch_request() File "/usr/lib/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request rv = self.handle_user_exception(e) File "/usr/lib/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception reraise(exc_type, exc_value, tb) File "/usr/lib/python2.7/site-packages/flask/app.py", line 1475, in full_dispatch_request rv = self.dispatch_request() File "/usr/lib/python2.7/site-packages/flask/app.py", line 1461, in dispatch_request return self.view_functionsrule.endpoint File "/home/karsten/Modularity/fm-orchestrator/rida/views.py", line 128, in submit_build for pkgname, pkg in mmd.components.rpms.packages.items(): AttributeError: 'NoneType' object has no attribute 'rpms'
@karsten is this still an issue?
Fix should be as easy as https://paste.fedoraproject.org/453848/67052831
Pasted here so fpaste doesn't expire::
diff --git a/rida/scheduler/handlers/components.py b/rida/scheduler/handlers/components.py index d391e58..9161fa9 100644 --- a/rida/scheduler/handlers/components.py +++ b/rida/scheduler/handlers/components.py @@ -90,6 +90,13 @@ def _finalize(config, session, msg, state): session.commit() return + if not current_batch: + log.debug("Hey batch is empty, I'm moving module build state to DONE") + parent.transition(config, models.BUILD_STATES['done']) + session.commit() + return + + def complete(config, session, msg): return _finalize(config, session, msg, state=koji.BUILD_STATES['COMPLETE'])
If there's at least one dependency or at least one component, then it should be legitimate.
If there are no deps and no components, then we should raise an error.
The case where a module has exactly one dep is kind of squirrely, but we want to preserve the ability to do that so we can re-brand or re-frame an existing module with new module metadata.
Fixed by #123.
@ralph changed the status to Closed
Closed
Login to comment on this ticket.