Switch from AUTH_LDAP_USER_DN_TEMPLATE to AUTH_LDAP_USER_SEARCH,
so we're more flexible:
AUTH_LDAP_USER_DN_TEMPLATE builds the user's DN (Distinguished Name)
directly from a template, without searching though (it assumes you know
the exact DN structure). While being faster, it's also less flexible.
AUTH_LDAP_USER_SEARCH on the other hand performs an LDAP search to find
the user, and by enabling SCOPE_SUBTREE we can also enable recursion.
This change is required to provide e.g. Jose from operations access
to our repoapi.
Also see MT#54080 for some historic information about those changes.
Change-Id: I30b3a3a5801ec3321ac67e533c32e5d4682c1ce3
We have a fixed value in config but for repoapi-dev it's just 1.
When doing tests, now that we have two slaves it's convenient to
be able to change that at will.
That could help too if we want to increase/decrease in the middle
of a already triggered build
Change-Id: I3c154ae2e3a754f995deb856e7b9b85ca1148107
In order to allow to keep information of failed builds. Before
we had to remove the info from a failed build in order to trigger
another full build.
Change-Id: I7cfcbedecdfed81951391fcdd84bb5be3c1b9e24
> if not br.last().done:
> logger.info(f"release:{release} is already building")
> > raise PreviousBuildNotDone(msg)
> E UnboundLocalError: cannot access local variable 'msg' where it is not associated with a value
Change-Id: I4b50fc8f328c24e6bec5ef940d5d7f4d4732e89b
Use --break-system-packages option as the new pip3 claims:
error: externally-managed-environment
...
note: If you believe this is a mistake, please contact your
Python installation or OS distribution provider. You can
override this, at the risk of breaking your Python
installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
Change-Id: I11b29dfe31a5404779b732923b6703670073a365
Since we are mounting in read-only mode the code, we are getting
warnings from pytest executions not able to generate .pytest_cache
directory.
Just define CACHE_DIR in a volumen that is mounted as read-write
Change-Id: I115f4ebcff78172fa809d0a9fdba02f923fb6ecb
Provide django command line jbi_files. The cleanup action
will archive build files of missing builds on database.
This will help to cleanup the huge amount of files we keep
right now in JBI_FILES
Change-Id: Ideb5a939807c41c411fa3883c0566221d7221189
We are storing some build artifact files indefinitely.
Implement removal of stored build artifacts on JenkinsBuildInfo
record deletion. So when a record in the database gets removed
the related files of that build will get relocated from JBI_FILES
to JBI_ARCHIVE
Change-Id: Ia1fcba2948bb3d0b50209fe29c1daa3f293cf59e
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
Michael Prokop
Jose Su
Victor Seva
Marco Capetta
Guillem Jover
Mykola Malkov