This works around a case where tagging messages are missed for a build
with high reuse. In such a case, we can start out in the final batch,
but have incorrect tag state for reused components from previous
batches.
This will enable building modules from the new libmodulemd v3 format.
This format fixes major issue with modularity which enables clear
upgrade paths for multicontext modules.
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
This is a fix and feature in one. This patch enables to use static
contexts instead of module stream expansion. This fixes the issue with
upgrade path issue in dnf.
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
Since ComponentBuildTrace(s) get created with db_session.commit() call,
is is not possible to commit more items in bulk if they already have been flushed.
Current unit-tests' setup can be significantly sped up if items can be quickly
flushed on the fly and bulk-commited only once at the end. Moreover in general it
seems more appropriate/safer to handle this in before_flush as any implicit
or accidental flush could cause new build traces not to be created at all. As flush
is implicitly called before every commit anyway, this change shouldn't pose any harm.
This function could get called multiple times if the init handler
runs more than once. This can happen if the build failed in the
init handler due to external infrastructure being down and the
user resumes their build.
- Implement new optional parameter module_stream to allow a scratch module
build's stream name to be set from the command line when also submitting a
YAML modulemd file.
- Validate that module_name and module_stream parameters can only be specified
along with a YAML modulemd file.
- Add tests to verify that module_stream sets the stream name correctly.
- Add tests to verify that module_name and module_stream are only allowed along
with a YAML modulemd file.
Signed-off-by: Merlin Mathesius <mmathesi@redhat.com>
Commit 98b1ac79 ensures the message is sent after data changes are
committed into database. Hence, it is doable to remove these two
workarounds.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
In MBS, there are two cases to send a message when a module build moves
to a new state. One is to create a new module build, with
ModuleBuild.create particularly, when user submit a module build.
Another one is to transition a module build to a new state with
ModuleBuild.transition. This commit handles these two cases in a little
different ways.
For the former, existing code is refactored by moving the publish call
outside ModuleBuild.create.
For the latter, message is sent in a hook of SQLAlchemy ORM event
after_commit rather than immediately inside the ModuleBuild.transition.
Both of these changes ensure the message is sent after the changes are
committed into database successfully. Then, the backend can have
confidence that the database has the module build data when receive a
message.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This also includes `from __future__ import absolute_import`
in every file so that the imports are consistent in Python 2 and 3.
The Python 2 tests fail without this.
