- Refactor MBS API code
- Unify module-/component_build API philosophy/design/approach
- Naming fixes
- _utc_datetime_to_iso moved from ModuleBuildAPI and is now a module-level function.
- Existing v1 API remains unchanged. ComponentBuildAPI now supports individual component build listing + verbose mode.
- documented in README
- various component_build API tests added
This should fix#523.
There, @james is right. Converting to "human" time values in an API
just makes things harder for API users. We should leave
human-conversion to real UIs (like cli tools or web UIs).
- DB migration scripts.
- Models: ComponentBuildTrace, ModuleBuildTrace.
- ModuleBuild.state_trace method for querying for a particular module's
state history.
- SQLAlchemy before commit session event handler for recording
module/component state changes.
- REST API verbose mode for getting state trace of a particular module.
- Tests use make_session, so that event handlers are in effect.
- Short info in README about verbose mode.
- Tests verifying whether state trace information about a module appears
in verbose mode.
- Other minor fixes (RidaBase -> MBSBase, PEP8...)
This is just so that the topic doesn't end up being super long like
`org.fedoraproject.prod.module_build_service.module.state.change`
The new value will be:
`org.fedoraproject.prod.mbs.module.state.change`
Currently, the only thing listening for this is pdc-updater, which I
will patch.
Fixes#181.
When initializing the buildroot for a module build, we used to set up
some build 'groups' for the tag: `build` and `srpm-build`. These are
the lists of RPMs that koji is supposed to install into the buildroot
before anything else is done. Crucial stuff goes here, like `git` in
the `srpm-build` group so that koji can clone the repo in the first
place.
We had those lists hardcoded before. This list changes that to use the
`buildroot` and `srpm-buildroot` profiles of the modules which are our
dependencies (recursively).
This will allow people like @psabata and the base-runtime to make
changes to the build groups for the generational core and work around
their own problems, instead of having to ask us to expand that list.
There were a couple ways to do this:
- I could've cloned the SCM repos for all dependencies and gotten their
profiles from the modulemd source there. This seemed flimsy because
we only want to depend on the profiles of modules that were *really*
built.
- We could modify PDC to stuff the modulemd contents in there. We
already get some dep and tag info from PDC. My thought here was that
it would be too heavyweight to store every copy of the modulemd file
in PDC for every build ever. We already have it in MBS.
- Lastly, and this is what I did here, I just referred to MBS' own
database to get the profiles. This seems to work just fine.
One side-effect is that we need the build profiles from the manually
bootstrapped modules that were put together by hand, and were never
built in the MBS. In order to work around that, I added an alembic
upgrade script which pre-populates the database with one fake
bootstrapped base-runtime module. We can expand on that in the future
if we need.
