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
When working on Debian/forky support, adding release-trunk-forky to
config/trunk.yml failed in Jenkins' repos-scripts-config-check with:
| + curl --fail -X POST --data-binary @config/trunk.yml -H 'Content-type: application/yaml' https://repoapi.mgm.sipwise.com/config/check/
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|
| 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
| 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
| 100 6725 0 0 100 6725 0 45930 --:--:-- --:--:-- --:--:-- 45748
| curl: (22) The requested URL returned error: 406
Initially it was unclear what was actually going on. Only after adding
some logging to /usr/share/repoapi/build/views.py, restarting
uwsgi.service on and then looking at /var/log/uwsgi/app/repoapi.log
revealed the underlying build.exceptions.NoUniqueTrunk exception.
Provide according details in the logs.log, but while at it, provide
further information also to the requester, so when invoking curl with
the --fail-with-body option (available in curl 7.76.0+), we get further
information about the actual problem:
% curl --fail-with-body -X POST --data-binary @trunk.yml -H 'Content-type: application/yaml' https://repoapi.mgm.sipwise.com/config/check/
curl: (22) The requested URL returned error: 406
{"error": "NoUniqueTrunk()", "type": "NoUniqueTrunk"}
Change-Id: I206591f14867ff35b2b5f90678ae53196a2fb043
This step was skipped/missed when initially creating the
repository with MT#60204 and therefore ngcp-logic-engine
was missing as project in the hotfix list.
Change-Id: I9be80a055f3da9d99d079d2c956214bfa24aa8a2
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
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
Michael Prokop
Guillem Jover
Jose Su
Victor Seva
Marco Capetta
Mykola Malkov