114 lines
3.3 KiB
Text
114 lines
3.3 KiB
Text
= Pagure Infrastructure SOP
|
|
|
|
Pagure is a code hosting and management site.
|
|
|
|
== Contents
|
|
|
|
[arabic]
|
|
. 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.
|