As of django-structlog v6.0.0, our django application fails with:
| Traceback (most recent call last):
| File "/var/lib/repoapi/venv_prod/lib/python3.9/site-packages/django/utils/module_loading.py", line 20, in import_string
| return getattr(module, class_name)
| AttributeError: module 'django_structlog.middlewares' has no attribute 'CeleryMiddleware'
Quoting from
https://django-structlog.readthedocs.io/en/latest/upgrade_guide.html#upgrading-to-6-0:
| (If you use celery) Make sure you use DJANGO_STRUCTLOG_CELERY_ENABLED = True
|
| It is only applicable if you use celery integration.
|
| django_structlog.middlewares.CeleryMiddleware has been remove in favor of a django settings.
|
| MIDDLEWARE += [
| "django_structlog.middlewares.RequestMiddleware",
| # "django_structlog.middlewares.CeleryMiddleware", # <- remove this
| ]
|
| DJANGO_STRUCTLOG_CELERY_ENABLED = True # <-- add this
Instead of forcing usage of an older django-structlog version,
let's make sure we have 6.0 or newer and update configuration
accordingly.
Change-Id: I0449c05db682ace22438b8b0ad8d8a4a1dfca71a
* migrate periodic task definition to database
via configuration
Be aware that we are getting hit by this issue:
https://github.com/celery/django-celery-beat/issues/647
Solution is not yet released:
2798e36fd8
Change-Id: Id72130bdd5fe97be3824f5d9d7a3905af44d3597
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
This reverts commit 1e2026769e.
This isn't a problem with python-debian, but in setuptools
itself, see https://bugs.debian.org/1041091
Change-Id: I0cef0bc444aa07060b07a1d7ca5a2301c77cd602
Instead of overwriting the install.log, let's append the output,
to make sure we capture all its output during our deployments.
Change-Id: I104694573cb5d94e33772df01d3d693539b188b5
> root@repoapi2:/usr/share/repoapi# source /var/lib/repoapi/venv_prod/bin/activate
> root@repoapi2:/usr/share/repoapi# export DJANGO_SETTINGS_MODULE=repoapi.settings.prod
Generate new apikey values, db is not changed!! This is just in order to
produce a apikey.json file:
> root@repoapi2:/usr/share/repoapi# ./manage.py apikey generate
> key:AsAPINOl.D7pq6PRT4hjpnb13LIMmjjafqoUJN8JN prefix:AsAPINOl hashed_key:pbkdf2_sha256$260000$EqQMpCFxh4Bk6nWMApv3PA$+8ZbfG+MXpBSOrXmc33fgBZZ7rUI4ywInOfUry+SKec=
Validate if a hash and key matches:
> root@repoapi2:/usr/share/repoapi# ./manage.py apikey verify --key AsAPINOl.D7pq6PRT4hjpnb13LIMmjjafqoUJN8JN --value 'pbkdf2_sha256$260000$EqQMpCFxh4Bk6nWMApv3PA$+8ZbfG+MXpBSOrXmc33fgBZZ7rUI4ywInOfUry+SKec='
Generate a hash from key:
> root@repoapi2:/usr/share/repoapi# ./manage.py apikey hash --value AsAPINOl.D7pq6PRT4hjpnb13LIMmjjafqoUJN8JN
pbkdf2_sha256$260000$i2AeV5mIwaKKAcisHZHTl4$ZvxWMfFJSXfkbf6SDUG2Ilv0MOtXq/Cy0PG6NNA48po=
Change-Id: I06bfe2f4e8cf08d3d75066cecf7e3fbf4c39680d
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
Automate the process of cleaning up the Gerrit info we keep.
We query Gerrit server and check if review is merged or abandoned.
If so, we remove data from database and query Jenkins to remove
the related PPA.
Ideally this should not be needed but it seems there are some
cases/scenarios that we don't manage properly.
* will be executed each 15th day of the month at 7:30
* add timezone info to Gerrit fixtures to reduce warning
Change-Id: Ic5ddc3b646532257bd7747443a6fdead4ff28544
* add dry-run option
checks gerrit review status and if merged, will trigger removal
of PPA if necessary
NOTE: this will not trigger removal of projects from PPA, just
removal of full PPA if no reviews are left
Change-Id: Iddebc80a92615d99ff8cd2f643ea49b5bfc106d6
gerrit URL needs a/ as prefix for authenticate access
https: //gerrit-review.googlesource.com/Documentation/rest-api.html#authentication
remove info from db that is not in gerrit
Change-Id: Icb49e4244fb058db0bb87ff27e7c8d8fe55c94d7
in order to be able to detect not cleaned PPA, lets keep
a mofified field to track last time a package was added
to the repository
Change-Id: I7f5d58cbc28d9c9ef54d90b69850fbedb80e4379
mrX.X.X merges will not trigger a build, so -repos job will never
happen with eventtype 'change-merged'
now -gerrit job sends the proper values of branch and ppa so
we can detect the scenario and clean the ppa
* move common regex definitions to repoapi.utils
Change-Id: I2b6afd0a7dea0fe07f47ba76bd6f9c2fa88e85ce
Marco Capetta
Michael Prokop
Guillem Jover
Victor Seva