You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would want to optionally allow for creation of tables/models to represent ABI information. A pre-requisite to this is being able to export it from libabigail in json, or have direct python bindings (this would be fun to try!) Specifically, we might have it so that when a package is added or updated, it triggers a worker to run a job to do extraction of ABI information (possibly static and binary information) to then update the database. I'll need to think about the best way to do this - we could have everything from a cloud based worker, to a worker with celery /redis (a little dated, but if the jobs are small it would work for development) or a more substantial setup of launching another instance.
The general idea is that the spec-based tables have the build provenance (and what works and doesn't) and the ABI tables should link back to these tables, but also have deployment type stuffs.
The text was updated successfully, but these errors were encountered:
This is currently modeled to receive xml (as text) from the libabigail analyzer, as we don't have support for gzip yet. I'm not sure how useful the big text objects are in the table, but we will need to figure out how we want to interact with this data, etc. I'll leave this open if anyone has comments.
We would want to optionally allow for creation of tables/models to represent ABI information. A pre-requisite to this is being able to export it from libabigail in json, or have direct python bindings (this would be fun to try!) Specifically, we might have it so that when a package is added or updated, it triggers a worker to run a job to do extraction of ABI information (possibly static and binary information) to then update the database. I'll need to think about the best way to do this - we could have everything from a cloud based worker, to a worker with celery /redis (a little dated, but if the jobs are small it would work for development) or a more substantial setup of launching another instance.
The general idea is that the spec-based tables have the build provenance (and what works and doesn't) and the ABI tables should link back to these tables, but also have deployment type stuffs.
The text was updated successfully, but these errors were encountered: