Learn more about these different git repos.
Other Git URLs
I have some old-style hooks in the Pagure instance that I maintain which up until now I've been adding as files to each repo that's supposed to have them (e.g. repos have hooks/pre-receive.myhook file). With Pagure 5.1, I'd like to transform them to the new-style hooks, which AFAICS requires them to have a DB table. I'm trying to figure out a good place to maintain schema migrations for these custom hooks. IIUC you can only have one alembic_version per a DB, so I'd need to add them to Pagure's upstream migrations. But that would also mean that I would diverge from the upstream chain of migrations for future releases, so that doesn't work either. The only solution I can think of right now is having a script that would just create/verify these tables on startup of my Pagure instance, but that's definitely not ideal. Do you have any better recommendations? Even if not, I think this should get documented for admins that would run in the same problem.
hooks/pre-receive.myhook
alembic_version
I think the DB table is only required if you want to let user activate/deactivate the hook.
Maybe we could expand pagure to consider more hooks like the default one (see some logic around the default plugin in pagure/lib/plugins.py)
pagure/lib/plugins.py
I'm even thinking the db table for the default hook could be entirely dropped since I think it's not really used (since it's always true)
The get_enabled_plugins function now requires that there's a backref on the project, which requires the table. I'd propose a third way of doing this - let's check for the backref or run a custom method (which every hook could create) of the hook with the project as an argument - if it returns True, the hook is to be run. This should allow us to have hooks without DB entries and doesn't break backwards compatibility - the default implementation of that method would return False every time. Does that make sense?
get_enabled_plugins
True
False
Does that make sense?
Sounds good to me :)
Metadata Update from @bkabrda: - Issue assigned to bkabrda
Commit 370e678 fixes this issue
Login to comment on this ticket.