Releasing eggs¶
Introduction¶
We maintain two egg distributions:
- Quaive private enterprise edition on pypi.quaive.net
- Ploneintranet community edition on pypi.python.org
Each of those is managed on a separate release branch.
These branches are needed so changes made during the release process are QA controlled via the normal pull request process.
Note
External theme resource package Since version 1.2.0a3, we depend on the pacakge quaive.resources.ploneintranet.
Note
Changelog Since version 1.2.69 we maintain the changelog manually, see https://github.com/quaive/ploneintranet/issues/1416 for details.
Creating a release¶
This shows how to cut a private 2.1.x release from master.
First, prepare the release branch:
user@host:~$ git checkout master
user@host:~$ git pull origin master
user@host:~$ git checkout release-2.1.x
user@host:~$ git pull origin release-2.1.x
user@host:~$ git merge master
You may need to work around zestreleaser.towncrier breakage:
user@host:~$ . bin/activate
Now you can start the release process:
user@host:~$ bin/prerelease
Run pyroma on the package before tagging? (Y/n)?
INFO: ------------------------------
INFO: Checking /home/ale/Code/plone/ploneintranet
INFO: Found ploneintranet
INFO: ------------------------------
INFO: Final rating: 10/10
INFO: Your cheese is so fresh most people think it's a cream: Mascarpone
INFO: ------------------------------
Do you want to run check-manifest? (Y/n)?
lists of files in version control and sdist match
WARNING: Found more than one file, picked the shortest one to change: CHANGES.rst, docs/about/history.rst
Enter version [2.1.x]:
INFO: Running command to update news: /home/ale/.local/bin/towncrier --version 2.1.x --yes
Loading template...
Finding news fragments...
Rendering news fragments...
Writing to newsfile...
Staging newsfile...
Removing news fragments...
Removing the following files:
/.../ploneintranet/news/...
...
Done!
Be sure that pyroma returns you a rating of 10/10 and that check-manifest reports “lists of files in version control and sdist match”.
If not please fix this.
Also check that the changelog file (CHANGES.rst) contains valuable informations and it is readable and that the news folder is empty.
Commit your changes and continue:
user@host:~$ bin/release
INFO: Starting release.
Tag needed to proceed, you can use the following command:
git tag 2.1.x -m "Tagging 2.1.x"
Run this command (Y/n)? Y
Check out the tag (for tweaks or pypi/distutils server upload) (Y/n)? Y
Register and upload to pypi (Y/n)? n
Register and upload to quaive (Y/n)? Y
Register and upload to cosent (Y/n)? n
Please make sure to not push a private release to pypi.python.org!
The new release is now available on pypi.quaive.net
Now push your commit:
user@host:~$ bin/postrelease
INFO: Starting postrelease.
Enter new development version ('.dev0' will be appended) [2.1.x+1]:
OK to commit this (Y/n)? Y
OK to push commits to the server? (Y/n)? Y
Merge the release changes¶
Please submit a new pull request from the release branch into master (go to https://github.com/quaive/ploneintranet/compare/release-2.1.x?expand=1). Do not delete the release branch, it will be re-used for subsequent releases.
See Git workflow for a full description of the Git workflow.
Update the Saturn deployment¶
We want to quality-check the new egg release by running a CI test on it.
If you don’t have a Saturn build already, initialize it, see below.
The Saturn buildout assumes that its buildout.d directory is identical to the ploneintranet buildout.d directory. If your release involved a change in ploneintranet/buildout.d e.g. a Plone upgrade, a new version pinning, or a new solr field, copy all the buildout.d configs to Saturn:
cp buildout.d/* ../saturn/buildout.d/ # or wherever your saturn build lives
Now go to saturn, update the ploneintranet pin:
cd ../saturn # or wherever your saturn build lives
sed -i 's/ploneintranet = .*/ploneintranet = 2.1.x/' buildout.cfg
git commit -am 'Release 2.1.x'
Obviously you’re supposed to change the release number to match the actual release you created above!
Finally, trigger a CI build by pushing the change:
git push gitlab master
git push origin master
Initializing a Saturn deploy build¶
If you don’t have a saturn build already, check it out:
git clone git@github.com:quaive/gaia.git
Add a remote for Gitlab pushes:
git remote add gitlab git@gitlab.com:quaive/gaia.git
Using a private egg release¶
Prepare your ~/.pypirc that contains the instructions
to authenticate to the private egg repository:
[distutils]
index-servers =
quaive
[quaive]
repository=http://pypi.quaive.net
username=foouser
password=barpassword
realm=http://pypi.quaive.net/
Add the this line to your buildout.cfg:
[buildout]
...
find-links +=
http://pypi.quaive.net/packages/
If you want to install the latest ploneintranet alpha/beta releases add:
[buildout]
...
prefer-final = false
or pin the ploneintranet version you desire, e.g.:
[versions]
...
ploneintranet = X.Y.ZaN
Instead of creating a ~/.pypirc file,
you can add the credentials to the URL in the find-links option, e.g.:
http://foouser:barpassword@pypi.quaive.net/packages/.
In this case remember to keep the file safe :)
You can use the saturn egg based deployment as a template.
Update quaive.resources.ploneintranet¶
This process requires to clone separetely quaive.resources.ploneintranet and releasing it to pypi.quaive.net:
git clone git@github.com:quaive/quaive.resources.ploneintranet.git
cd quaive.resources.ploneintranet
make all
fullrelease
Take note of the released egg version, and update the file buildout.d/versions.cfg in order to match it, e.g.:
[versions]
# Quaive packages
quaive.resources.ploneintranet = 1.2.0a1
Make a pull request to quaive/ploneintranet with this changes.
Managing users on pypi.quaive.net¶
You can only add users if you have shell access:
user@host$ ssh pypi@pypi.quaive.net
pypi@cs02:~$ cd pypiserver/
pypi@cs02:~/pypiserver$ htpasswd var/quaive/htpasswd.txt johndoe
New password:
Re-type new password:
Adding password for user johndoe
Ask Guido to add your users if you do not have ssh access.
