The 2.14 release brings some adjustments to the database scheme.
alembic upgrade head
The 2.13 release brings some adjustments to the database scheme.
alembic upgrade head
From this release on, we will have alembic migration script for new table
creation, so there will no longer be a need to use createdb.py
The 2.12 release brings some adjustments to the database scheme.
alembic upgrade head
The 2.10 releases brings some adjustments to the database scheme.
createdb.py
alembic upgrade head
The 2.10 releases brings some little changes to the database scheme.
Therefore when upgrading to 2.10, you will have to:
alembic upgrade head
The 2.9 releases brings some adjustments to the database scheme.
createdb.py
alembic upgrade head
If you are interested in loading your local data into the pagure_logs
table
that this new release adds (data which is then displayed in the calendar heatmap
on the user's page), you can find two utility scripts in
https://pagure.io/pagure-utility that will help you to do that. They are:
pagure_logs
table (this will add: new ticket, new comment, new
PR, closing a PR or a ticket and so on).2.8 brings a little change to the database scheme.
Therefore when upgrading to from 2.7 to 2.8, you will have to:
alembic upgrade head
2.7 adds new tables as well as changes some of the existing ones.
Therefore when upgrading to 2.7, you will have to:
createdb.py
script.PAGURE_CONFIG=/path/to/pagure.cf alembic upgrade head
This release also brings a new configuration key:
INSTANCE_NAME
used in the welcome screen shown upon first login (only with
FAS and OpenID auth) to describe the instanceThe API has also been upgraded to a version 0.8
due to the changes (backward
compatible) made to support the introduction of close_status to issues.
2.6 brings quite a few changes and some of them impacting the database scheme.
Therefore when upgrading from 2.4 to 2.6, you will have to:
alembic upgrade head
2.5 brings quite a few changes and some of them impacting the database scheme.
Therefore when upgrading from 2.4 to 2.5, you will have to:
alembic upgrade head
2.4 brings quite a few changes and some of them impacting the database scheme.
Therefore when upgrading from 2.3.x to 2.4, you will have to:
alembic upgrade head
This update also brings some new configuration keys:
VIRUS_SCAN_ATTACHMENTS
allows turning on or off checking attachments for
virus using clamav. This requires pyclamd but is entirely optional (and off by
default)PAGURE_CI_SERVICES
allows specifying with which CI (Continuous
Integration) services this pagure instance can integrate with. Currently, only
Jenkins is supported, but this configuration key defaults to None
.2.3 brings a few changes impacting the database scheme, including a new duplicate status for tickets, a feature allowing one to watch or unwatch a project and notifications on tickets as exist on pull-requests.
Therefore, when upgrading from 2.2.x to 2.3, you will have to :
createdb.py
script.alembic upgrade head
This update also brings a new configuration key:
PAGURE_ADMIN_USERS
allows to mark some users as instance-wide admins, giving
them full access to every projects, private or not. This feature can then be
used as a way to clean spams.SMTP_PORT
allows to specify the port to use when contacting the SMTP
serverSMTP_SSL
allows to specify whether to use SSL when contacting the SMTP
serverSMTP_USERNAME
and SMTP_PASSWORD
if provided together allow to contact
an SMTP requiring authentication.In this update is also added the script api_key_expire_mail.py
meant to be
run by a daily cron job and warning users when their API token is nearing its
expiration date.
Release 2.2.2 contains an important security fix, blocking a source of XSS attack.
2.2 brings a number of bug fixes and a few improvements.
One of the major changes impacts the databases where we must change some of the table so that the foreign key cascade on delete (fixes deleting a project when a few plugins were activated).
When upgrading for 2.1 to 2.2 all you will have to do is:
alembic upgrade head
Note
If you run another database system than PostgreSQL the alembic
revision 317a285e04a8_delete_hooks.py
will require adjustment as the
foreign key constraints are named and the names are driver dependant.
2.1 brings its usual flow of improvements and bug fixes.
When upgrading from 2.0.x to 2.1 all you will have to:
alembic upgrade head
As the version change indicates, 2.0 brings quite a number of changes, including some that are not backward compatible.
When upgrading to 2.0 you will have to:
alembic upgrade head
createdb.py
scriptForked git repos are now located under the same folder as the regular git
repos, just under a forks/
subfolder.
So the structure changes from:
repos/ ├── foo.git └── bar.git forks/ ├── patrick/ │ ├── test.git │ └── ipsilon.git └── pingou/ ├── foo.git └── bar.git
to:
repos/ ├── foo.git ├── bar.git └── forks/ ├── patrick/ │ ├── test.git │ └── ipsilon.git └── pingou/ ├── foo.git └── bar.git
So the entire forks
folder is moved under the repos
folder where
the other repositories are, containing the sources of the projects.
Git repos for tickets
, requests
and docs
will be trickier to
move as the structure changes from:
tickets/ ├── foo.git ├── bar.git ├── patrick/ │ ├── test.git │ └── ipsilon.git └── pingou/ ├── foo.git └── bar.git
to:
tickets/ ├── foo.git ├── bar.git └── forks/ ├── patrick/ │ ├── test.git │ └── ipsilon.git └── pingou/ ├── foo.git └── bar.git
Same for the requests
and the docs
git repos.
As you can see in the tickets
, requests
and docs
folders there
are two types of folders, git repos which are folder with a name ending
with .git
, and folder corresponding to usernames. These last ones are
the ones to be moved into a subfolder forks/
.
This can be done using something like:
mkdir forks for i in `ls -1 |grep -v '\.git'`; do mv $i forks/; done
This can be done via the Re-generate gitolite ACLs file
button in the
admin page.
The support of pseudo-namespace in pagure 2.0 has required some changes to the URL schema: https://pagure.io/pagure/053d8cc95fcd50c23a8b0a7f70e55f8d1cc7aebb became: https://pagure.io/pagure/c/053d8cc95fcd50c23a8b0a7f70e55f8d1cc7aebb (Note the added /c/ in it)
We introduced a backward compatibility fix for this.
This fix is however disabled by default so if you wish to keep the URLs valid, you will need to adjust you configuration file to include:
OLD_VIEW_COMMIT_ENABLED = True