#3972 DB migrations for custom hooks
Closed: Fixed 5 years ago Opened 5 years ago by bkabrda.

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.


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)

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?

Does that make sense?

Sounds good to me :)

Metadata Update from @bkabrda:
- Issue assigned to bkabrda

5 years ago

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #3978 Merged 5 years ago