Adjust the production distgit and MBS configuration to allow
having a separate flatpaks/ namespace and building from there.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
The cert is now for rabbitmq.stg.fedoraproject.org and not:
rabbitmq01.stg.phx2.fedoraproject.org so having the wrong url in the config
leads to a CertificateError leading to pagure failing to send notifications
on fedora-messaging.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
Change the distgit staging configuration to allow a flatpaks/ namespace,
and configure Koji and MBS to allow building from there.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
This way it'll try to interact with the DB using async processes
(the workers) rather than trying to do it where it does not have
the permissions and crash.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
This leads to some exception being raised instead of by-pass safely.
It was useful at some point because pagure would not log error to
its logs otherwise but Patrick has since fixed it and I believe it
may be triggering some errors now.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
So in out dist-git setup the git hook have a dedicated configuration
file which only contains a read-only access to the database.
This is because of the way our dist-git is setup where every packager
actually has a shell account on the machine and the hook are run by
that account.
So if the packager manages to get a shell access, they will be able to
read this configuration file and we do not want to give them read/write
access to the database.
Pagure however in the default hook tries to update the database, among
other it tries to clear the cached merge status of the open PR when a
commit is pushed.
For a nice UX, it does this within the hook process, this way there is
no race-condition and users accessing a PR right after a push will get
an up to date merge status (as it will be re-generated).
But we cannot do this in dist-git since we cannot update the database
directly, so instead, with this hotfix, we move the process of cleaning
up the merge status to an async job that will have read/write access
and there may be some race-condition in displaying the merge status
but so be it.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
This is necessary because of the way our dist-git is deployed, the git hook
only have a read-only access to the database so they can't reset the cached
merge status of the open PRs in the same process so we need to do this via
an async process which is basically what this hotfix does.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
