* calling build from API was always unauthorized
* drfapikey only supports Django until 1.10 version
* https://florimondmanca.github.io/djangorestframework-api-key/
supports modern Python and Django versions
- remove useless BUILD_KEY_AUTH preference, it's True always
Change-Id: I5521b07532dba12abea52982d376eb83293f6a38
* mock is now part of the Python standard library,
available as unittest.mock in Python 3.3 onwards.
https://pypi.org/project/mock/
Change-Id: Id5a5d4a5020821def08a3cbf2a6d528d43c4d48c
- Features deprecated in 2.1:
* {% load staticfiles %} and {% load admin_static %} are deprecated in
favor of {% load static %}, which works the same.
- Features deprecated in 1.10:
* Session verification will be enabled regardless of whether or not
'django.contrib.auth.middleware.SessionAuthenticationMiddleware' is
in MIDDLEWARE_CLASSES.
- django-filters:
* https://django-filter.readthedocs.io/en/stable/guide/rest_framework.html
- django-rest-framework:
https://www.django-rest-framework.org/api-guide/pagination/
"Note that you need to set both the pagination class, and the page size that
should be used. Both DEFAULT_PAGINATION_CLASS and PAGE_SIZE are None by default."
- t/Dockerfile: migrate to bullseye
Change-Id: Ia225eba15ca46446700fa2699e89d7e4601bf1a2
tap-tests docker is generated now per release so we need to add the repo
to docker projects to be able to trigger docker rebuild from repoapi
interface.
Change-Id: I822aa87b26b6ba4cd8a1385828dcaad6755bc921
* Makefile: add extra test summary
* migrate to structlog, this is an ongoing effort
* panel: remove any "trunk" build
Change-Id: I6f60541248f2970e0fe0784f2eb6eff5dec40721
* release has to be 'release-mrX.Y-update' when the build is not the
first
* add check in model, already in view, to don't allow to build more
than one mrX.Y.Z release
* don't trigger copy_debs on release '*-update' builds
* fix BuildRelease.done property, now we can have no
BUILD_RELEASE_JOBS in the list
* BuildReleaseManager.release() in order to get all the BuildRelease
related to the same version now that we have 'release-mrX.Y-update'
Change-Id: I610a246c2f5fc3574153fd226837a060185c379d
* for releases mrX.X and trunk when old builds are done
* add last_update info in the list of builds
* fix error when running tests on local docker
Change-Id: I4912aa00f1a09141ff5d9babfb7b09217097c3d4
settings.DEBUG doesn't have the proper value defined at settings.dev
use override_settings in BaseTest to fix it and use it on all apps
if necessary
Add a test and mark as expectedFailure to document this
Change-Id: I2017bf695469f4d98db9e5278e43a9e89b5a6be5
This will help us when jumping to Django 2+
> /code/repoapi/urls.py:93: RemovedInDjango20Warning: Specifying a namespace in
> django.conf.urls.include() without providing an app_name is deprecated. Set
> the app_name attribute in the included module, or pass a 2-tuple containing the list of patterns
> and app_name instead.
> url(r"^build/", include("build.urls", namespace="build")),
* py-test: set norecursedirs due to 'build' is in the default
so build app was not included in the test
* py-test: raise errors if warnings from Django are detected
from repoapi
Change-Id: Iab74024a435c1d7851cfe5a51f0ae54a044791a3
This will help us when jumping to Django 2+
> RemovedInDjango20Warning: Importing from django.core.urlresolvers is deprecated in favor of django.urls.
Change-Id: I13c3e1e8aea93aa48d1f7997eb6daae3b7dcfecc
* list of supported releases is only going to grow
better to group them
* add some more config yaml files to able to produce
groups in test
Change-Id: I13fa7e6f3de08b5f131dc5c19cfd28d0ed7a4f53
* 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
We usually use either "ignore" or "branch/master" and those are within
the 15 character limits of BuildTrunkDepForm() and
BuildTrunkReleaseForm().
But when building against "branch/stretch/master" or
"branch/buster/master", we trigger a `form validation error` because
both branch/stretch/master and branch/buster/master have more than 15
characters.
Raise character limit from 15 to 30 characters.
Change-Id: Icc1f8ee46dcb250c2d40da9ca25fef0d6924db1e
If we want to trigger a trunk build against e.g. Debian/buster we
might need to build certain projects against branch "buster/master",
instead of using the default "master" branch (which works fine for the
current Debian stable release AKA stretch, but might need
non-backwards compatible changes when building for the current Debian
testing release AKA buster ).
I identified two approaches to get there:
1) Statically extend the list of available branches which is available
for selection in the "Version" drop down (which only provide "ignore"
and "branch/master" until now).
This could be done by something like:
| --- a/release_dashboard/utils/__init__.py
| +++ b/release_dashboard/utils/__init__.py
| @@ -14,6 +14,7 @@
| # with this program. If not, see <http://www.gnu.org/licenses/>.
|
| from release_dashboard.models import Project
| +from release_dashboard.forms import rd_settings
|
|
| def get_tags(projectname, regex=None):
| @@ -23,4 +24,8 @@ def get_tags(projectname, regex=None):
|
| def get_branches(projectname, regex=None):
| project, _ = Project.objects.get_or_create(name=projectname)
| - return project.filter_branches(regex)
| + branches = project.filter_branches(regex)
| + for debian_release in rd_settings['debian_supported']:
| + if debian_release != "auto":
| + branches.append(debian_release + "/master")
| + return branches
The disadvantage of this approach is, that we're listing all the
branches all the time, e.g. the very old "squeeze/master" is listed
even though it doesn't exist in any project as such.
2) Identify available branches and extend the regular expression
which identifies the "master" branch by also looking for
"$debian_release/master" branches, iterating over all supported
Debian releases.
Since approach 2) doesn't polute the drop down for branch
selection so much, this is the solution I decided to use here.
JFTR, when testing locally against an unpopulated sqlite database (:=
db.sqlite3 file), then the relevant branches need to exist in the
release_dashboard_project table of the DB. To fake such data use
something like:
| root@16f2201e3229:/code# sqlite3 ./db.sqlite3
| SQLite version 3.16.2 2017-01-06 16:32:41
| Enter ".help" for usage hints.
| sqlite> update release_dashboard_project set json_branches = '[{"ref": "HEAD", "revision": "master"}, {"ref": "refs/heads/master", "revision": "fakedata"},
| {"ref": "refs/heads/buster/master", "revision": "fakedata"}, {"ref": "refs/heads/stretch/master", "revision": "fakeeeeee"}]';
Change-Id: I5f24574e33ac80d1e92210ff5516dce4bf8fef76
Sergii Kipot
Victor Seva
Michael Prokop
Robert Axelsen
Manuel Montecelo