More than two years since last release (dating back to 2024-10-09),
given we updated to Django v5.2.17, let's use this as opportunity to
bump its version number.
Fix broken changelog idention, while at it
Change-Id: I450a9e725ffe1932a6aab9218f941b1ad885d968
On fresh installation, the pyvenv.cfg doesn't exist yet:
| sed: can't read /var/lib/repoapi/venv_prod/pyvenv.cfg: No such file or directory#015
| dpkg: error processing archive /var/cache/apt/archives/repoapi_0.4.8+0~20261005122448.1256+trixie~1.gbp3fa7df_all.deb (--unpack):#015
| new repoapi package pre-installation script subprocess returned error exit status 2#015
| Errors were encountered while processing:#015
| /var/cache/apt/archives/repoapi_0.4.8+0~20261005122448.1256+trixie~1.gbp3fa7df_all.deb#015
Followup fix for 3fa7dfeb89
Change-Id: I02d84af341681a410a3b83e2aba363176ebd0a42
When we upgrade the package we might be doing so while the base
distribution has been upgraded and the Python version has changed.
In that case we need to remove the virtual environment so that we force
it to be regenerated. We check whether the system Python has the same
version as the virtual environment version, and if they do not match,
we remove it.
This change makes the current logic future proof, as we do not need to
keep changing the package version check to match a release boundary.
Change-Id: Ie4fcf3ffabcfa2adfba21a633baeefd9a87a5c32
If we generate the secret key and then change its permissions, we leave
a race-condition where an observer can try to open or read the contents
before the permissions have been reduced.
Improve the progress reporting to print a message when we start and once
we are done.
Change-Id: Idef205ae9e687a0439c68a58793477e9d8347836
When invoking `virtualenv --python=python3 virtualenv` to deploy the
virtual environment, installing the python-debian wheel, and then
re-executing `virtualenv --python=python3 virtualenv` once again, we
might end up without the virtualenv/lib/python*/site-packages/debian
directory, resulting in:
| Traceback (most recent call last):
| File "<string>", line 1, in <module>
| ModuleNotFoundError: No module named 'debian'
This is a bug in setuptools >=51.3.3-1, see
https://bugs.debian.org/1041091 for the details, so currently affecting
all systems with Debian/bookworm.
By excluding installation of setuptools (via --no-setuptools), we would
be able to work around this bootstrapping problem itself, though then
installation of django-jsonify (which we depend on) fails with:
| ModuleNotFoundError: No module named 'setuptools'
Let's take this as a chance to switch from virtualenv to the more
lightweight venv, quoting https://docs.python.org/3/library/venv.html:
| Changed in version 3.5: The use of venv is now recommended for creating virtual environments.
Change-Id: Iad06bf8c49abd96441ab04bb9b7e3917acd1ee59
The python binary is gone, and use and support python3 instead.
Fixes:
| Setting up repoapi (0.4.6+0~20230705093550.1012+bookworm~1.gbp7c23af) ...
| /var/lib/dpkg/info/repoapi.postinst: 21: python: not found
| dpkg: error processing package repoapi (--configure):
| installed repoapi package post-installation script subprocess returned error exit status 127
Change-Id: I54c02826da75fb2a01ee307aeab850978034c9da
* set default tracker to mantis, None for test/dev
* debian: add missing sipwise-workfront-tools dependency
Added as Recomends since we are not going to use it
in the near future
* MANTIS_* settings
Change-Id: Id7b19f23d316a31b362112167edb5c395baf554b
new fields at server.ini file needed!!
* AUTH_LDAP_GROUP_BASE: LDAP base query for get posixGroups
* AUTH_LDAP_REQUIRE_GROUP_LIST: coma separated list of required groups
Change-Id: If82b983aabe8cebc0491c04d467e955b503956d3
check-ngcp-release-changes job will send via jbi its info. Then
the app will process the data and keep it to provide
/release_changed/<vmtype>/<version>/ URL to check the status. Will
respond with 200 OK if the result was SUCCESS and 404 with NOT_FOUND
otherwise.
Change-Id: I242003cf2b01ae235e47d1a1d1a26aaabd9eb82e
* smart build release reading per release metadata file
provided by sipwise-repos-scripts-data package
* build release will trigger settings.RELEASE_JOBS jobs first
* old build process hidden at /release_panel/old/
as a fallback just in case
* some examples of config/<release>.yml files
just for test
* style changes by black pre-commit plugin to unify
code style
* rework panel.js to support both views /release/ and /release_uuid/
via $.release.uuid value
* cosmetic improvements
Change-Id: I5f581100e6c297a1cc0abc4bb1ddf978870b6936
Set debhelper compat level in Build-Depends instead of debian/compat.
Do not explicitly request the systemd sequence.
Use dh_installsystemd instead of deprecated dh_systemd_*.
Change-Id: Ic8cbf795de90aa8900a899706ce6e0474a8e6eed
Merge two file stanzas for Sipwise copyright, and use the one with the
canonical Sipwise copyright entity.
Change-Id: I68abd326d976d1db99e119c88d834662daf824d8
- Bump debhelper compatibility version 10.
- Switch from Priority extra to optional.
- New debian/.gitignore file.
- Canonicalize Homepage URL.
- Remove dh-make boilerplate in debian/rules.
Change-Id: Ic731001d847b143ae9d0bbc6ca23202b39003f67
Lots of changes, time for a new release, since it's a switch
from Python2 to Python3, updating Django and its components
and switch from Debian jessie to stretch let's bump the minor
version number.
Change-Id: Id400901510e34f6c90e8eea538fe0f24acb23dd0
Updates:
* Debian jessie->stretch (to use current stable Debian version)
* Python 2.7->3.5 (since Python v2 won't be supported with the
next Django LTS version any longer and we want to be prepared)
* Improve uwsgi configuration for production usage while at it
(thanks Florian Apolloner for feedback and suggestions)
Necessary changes:
* Debian:
- we need to use uwsgi-plugin-python3 for Python3 support
- replace python-dev with python3-dev for Python3 support
and python with python3 accordingly
- get rid of __pycache__ directories to avoid inclusion in
resulting Debian package
* uwsgi:
- if we hardcode python34 (for jessie) or python35 (for stretch)
then we can't run uwsgi on all supported systems, so instead
try `plugin = python3` and rely on update-alternatives mechanism
of uwsgi-plugin-python3 Debian package to get it right for,
if that shouldn't work as needed then we can look into
/usr/share/python3/runtime.d/uwsgi-plugin-python3.rtupdate
or shipping repoapi.ini via puppet instead
* docker:
- python-distribute is not needed (anymore)
- adjust package names for Python3 usage, support jessie
and stretch at the same time
- note: just replacing 'stretch' with 'jessie' in t/Dockerfile
is enough to get a working repoapi docker image based on jessie
* Python3:
- assertItemsEqual became assertCountEqual
- mocking: `__builtin__.open` became `builtins.open`, see
https://stackoverflow.com/questions/1289894/how-do-i-mock-an-open-used-in-a-with-statement-using-the-mock-framework-in-pyth
- we need six >=1.9.0 for raise_from astraction in py3
Otherwise we're failing on Debian/jessie with:
| AttributeError: 'module' object has no attribute 'raise_from'
See https://github.com/benjaminp/six/blob/master/CHANGES
- assert_has_calls changes, fixes:
| AssertionError: Calls not found.
| Expected: [call('345', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered'),
| call('123', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered')]
| Actual: [call('123', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered'),
| call('345', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered')]
See https://docs.python.org/dev/library/unittest.mock.html#unittest.mock.Mock.assert_has_calls
- urllib:
- `from urlparse import urlparse` became `from urllib.parse import urlparse`
- `urllib.quote` became `urllib.parse.quote`
- configparser:
- `from ConfigParser import ...` became `from configparser import ...`
* Django:
- 'from views import ...' became 'from .views import ...'
- the "TEMPLATE_DIRS" setting needs to go into "TEMPLATES = [ { 'DIRS': [ ...."
nowadays, see https://docs.djangoproject.com/en/1.11/ref/templates/upgrading/
* celery:
- to use latest celery version 4 django-celery needs to be replaced
by django-celery-beat + django-celery-results
(otherwise we're running into https://github.com/celery/django-celery/issues/497),
see documentation at http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
- adjust systemd unit files to use ExecStart
| ExecStart=/var/lib/repoapi/venv_prod/bin/celery -A repoapi [...]
instead of
| ExecStart=/var/lib/repoapi/venv_prod/bin/python3 ./manage.py celery [...]
and use `--db=/var/lib/repoapi/flower` instead of
`--db=/var/lib/repoapi/flower.db` to avoid ending up with a file
named flower.db.db
Notes for migration (assuming root permissions):
- get rid of existing flower database (not containing relevant data):
mv /var/lib/repoapi/flower.db /var/lib/repoapi/flower.db.old
- re-deploy virtual environment from scratch:
mv /var/lib/repoapi/venv_prod /var/lib/repoapi/venv_prod.old
cd /usr/share/repoapi && make deploy
- service restarts (in case of virtual env changes):
systemctl restart nginx
systemctl restart repoapi-beat.service
systemctl restart repoapi-flower.service
systemctl restart repoapi-worker.service
systemctl restart uwsgi
- usage instructions for celery + django stuff:
/var/lib/repoapi/venv_prod/bin/celery flower --help
source /var/lib/repoapi/venv_prod/bin/activate && ./manage.py help --settings="repoapi.settings.prod"
- create superuser for django administration (https://repoapi*.mgm.sipwise.com/admin/):
source /var/lib/repoapi/venv_prod/bin/activate && ./manage.py createsuperuser --settings="repoapi.settings.prod"
Thanks: Victor Seva for assistance with porting
Change-Id: Iacb48bf5dadf4eae97b5fbe944e44370e525f64c
* using https://github.com/manosim/django-rest-framework-api-key
for Permissions. Will generate an Auth KEY for jenkins to be able
to trigger build from there using build REST API
* store the info needed to trigger builds for a set of projects for
a release
- build is a list of projects to be built with branch or tag as orig
and release as destination for a debian distribution
* added release_uuid to JenkinsJobInfo model
- release_uuid is the way to group project builds for a release
- tag works for group of jobs for a project
Change-Id: Iebeaa54308c3e569a167f55d98c184b52248af8a
* provide info of actual images and tags
* refresh docker images/tag via release_dashboard
* keep that info in db
* fix Dockerfile documentation
* cleanup thanks to flake8
Change-Id: I743482da9b4d50f7b1832cad324882f3a49cbcf0
* update dependencies due postgresql
* fake files needed to deploy at debian
* add new needed config values at server.ini file
Change-Id: I02699c721ac79a0328da07a4c2e3a2cb1451d403
In order to be able to deploy that file with different values
depending on the server so we can use -dev.mgm services on
repoapi-dev.mgm
Change-Id: I2f5546c4f664707250ab89f29e71d4092c848890
Michael Prokop
Guillem Jover
Victor Seva
Alexander Lutay