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
Git daemon which provided Sipwise anonymous access to
internal Git repository is deprecated. Also it is
useless to point public GitHub repository to the internal git server.
Change-Id: Ib96777255b69bebf590fadf1cab9aadaa58400b5
* remove uwsgi configs for them
* manage secret_key and virtualenv on postinst
* restart uwsgi on postinst
* add missing uwsgi as dependency
Change-Id: I40a85e75d3961c7e84d49fce5e3026064cac1d56
Victor Seva
Guillem Jover
Michael Prokop
Alexander Lutay