infra-docs-fpo/modules/sysadmin_guide/pages/pagure.adoc

= Pagure Infrastructure SOP

Pagure is a code hosting and management site.

== Contents

* <<_contact_information>>
* <<_description>>
* <<_when_unresponsive>>
* <<_git_repo_locations>>
* <<_services_and_what_they_do>>

== Contact Information

Owner::
  Fedora Infrastructure Team
Contact::
  #fedora-apps
Location::
  OSUOSL
Servers::
  pagure01, pagure-stg01
Purpose::
  Source code and issue tracking

== Description

Pagure ( https://pagure.io/pagure ) is a source code management and
issue tracking application. Its written in flask. It uses: celery,
redis, postgresql, and pygit2.

== When unresponsive

Sometimes pagure will stop responding, even though it's still running.
You can issue a 'systemctl reload httpd' and that will usually get it
running again.

== Git repo locations

* Main repos are in `/srv/git/repositories/<projectname>`
* issue/ticket repos are under
`/srv/git/repositories/tickets/<projectname>`
* Docs are under `/srv/git/repositories/docs/<projectname>`
* Releases (not a git repo) are under `/var/www/releases/`

== Services and what they do

* `pagure` service is the main flask application, it runs from httpd wsgi.
* `pagure_ci` service talks to jenkins or other CI for testing PR's
* `pagure_ev` service talks to websockets and updates issues and comments
live for users.
* `pagure_loadjson` service takes issues loads from pagure-importer and
processes them.
* `pagure_logcom` service handles logging.
* `pagure_milter` processes email actions.
* `pagure_webhook` service processes webhooks to notify about changes.
* `pagure worker` service updates git repos with changes.

== Useful commands

This section lists commands that can be useful to fix issues encountered
every once in a while.

* Recompile the gitolite configuration file
+
....
# sudo -u git HOME=/srv/git/ gitolite compile && sudo -u git HOME=/srv/git/ gitolite trigger POST_COMPILE
....
* Duplicated projects

We have observed that every so often two different workers create a
project in the database. This leads to pagure failing to give access to
the project as it finds multiple projects with the same namespace/name
where it expects these to be unique.

The following two SQL commands allows finding out which projects are in
this situation:

....
select user_id, name, namespace, is_fork from projects where is_fork =
FALSE group by namespace, name, is_fork, user_id having count(user_id) >
1;

select user_id, name, namespace, is_fork from projects where is_fork =
TRUE group by namespace, name, is_fork, user_id having count(user_id) >
1;
....

This will return you the _namespace_/_name_ as well as the _user_id_ of the
user who duplicated the projects in the database.

You can then do:

....
select id, user_id, name, namespace, is_fork from projects where name =
'<the name of the project>' order by user_id;
....

In that query you will see the project _id_, _user_id_, _name_ and _namespace_
of the project. You will see in this one of the projects is listed twice
with the same _user_id_ (the one returned in the previous query).

From there, you will have to delete the duplicates (potentially the one
with the highest project id).

If the project remains un-accessible, check the apache logs, it could be
that the git repositories have not been created. In that case, the
simplest course of action is to delete all the duplicates and let the
users re-create the projects as they wish.