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
Tasks should deal only with serialize/de-serialize parameters
work need to be external so it can be tested easily
* don't call a task directly in tests that causes:
> ======================================================================
> ERROR: test_hotfixreleased (hotfix.test.test_hotfix_released.TestHotfixReleased)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/code/venv_dev/lib/python3.7/site-packages/kombu/utils/objects.py", line 42, in __get__
> return obj.__dict__[self.__name__]
> KeyError: 'backend'
Change-Id: I620f10d5c58563cc4af2898429bbe1a9a60007b5
* skip pylint check for now, lots of changes needed to pass
* tmux.sh support using a different tag for repoapi image
this helps to download a tag from a review localy and
hack
Change-Id: I63f034d9d4b73f7e6eb69b0cd3ad6f731281f806
* build: don't fail if no builds on done property
* fix progress stats on panel_uuid
* stop sending queries if release is done
Change-Id: I4fb4c6c161a852bb8f5ee978cec053d98e38a1f8
* added mr8.1.2 and data to test it
* don't add project as failed for piuparts job with FAILURE status
Change-Id: I95a8bdbf5a73b4f353d99bc172f879a90870e1f0
Adds support to export data using filters
to yaml via django admin interface
* add tmux.sh helper and update README.md
* requirements: set max supported versions for django 1.11
https://github.com/praekelt/django-export
Change-Id: Ia9af0610725795c588e0bafd06cd6cfcffd9873f
* 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
* for running on dev environment point to README.md on Dockerfile
* add watchdog for dev to decrease IO/CPU workload as documentation suggests
> https://django-extensions.readthedocs.io/en/latest/runserver_plus.html
* coverage.rc file to define where to store data
needed on jenkins environment where only results dir has rw perms
* use my own fork for django-jenkins until project is back alive
Change-Id: If3d9b442759a2841ff3441609c3164987fbbb6c5
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
Fixes:
| No attribute 'code' on urllib.request._HTTPResponse [attribute-error]
as reported by pytype.
The urllib module has been split into parts and renamed in Python 3 to
urllib.request, urllib.parse, and urllib.error, and therefore will fail
with:
| AttributeError: module 'urllib' has no attribute 'request'
This used to work only because other components loaded within repoapi
did the `import urllib.request` for us.
Also the errors were never reported as such, as e.g. 404 errors are
throwing an exception (instead of provided as return code as expected by
our code so far), which we didn't catch so far. And the arguments
provided to logger/ logging were incorrect (number vs string), so fix
this and also slightly improve the logging messages while at it.
JFTR, `import urllib.request` is py3k-only, which is fine for us though,
since repoapi is supporting only py3k nowadays. We should also think
about migrating from urllib towards requests everywhere.
Change-Id: Ibc965daa94216aaad80758dba0f50a74d8658887
Otherwise building against Debian/buster with python 3.7 fails with:
| File "/build/repoapi-0.3.0+0~20190702124241.289+buster~1.gbp167a8a/venv_prod/lib/python3.7/site-packages/django/contrib/admin/widgets.py", line 151
| '%s=%s' % (k, v) for k, v in params.items(),
| ^
| SyntaxError: Generator expression must be parenthesized
The underlying issue is #32012 in python (see
https://bugs.python.org/issue32012), which disallows ambiguous syntax
f(x for x in [1],), which is fixed only with Django >=1.11.17, see
931c60c521
Quoting from https://docs.djangoproject.com/en/dev/faq/install/#what-python-version-can-i-use-with-django:
| Django version | Python versions
+----------------+-------------------------------------------
| 1.11 | 2.7, 3.4, 3.5, 3.6, 3.7 (added in 1.11.17)
| 2.0 | 3.4, 3.5, 3.6, 3.7
| 2.1, 2.2 | 3.5, 3.6, 3.7
| 3.0 | 3.6, 3.7, 3.8
Change-Id: I4a1db7488792e5374c0f82629dfcfba0a6419be5
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
Calling sorting after every single project processing causes
huge overload during initial page load because the same DOM
part is removed, sorted and then added back by many callbacks
at the same moment. So let's disable it.
This function sorts the list of projects under each progress bar.
It's not critical to have the list sorted there so let's remove
sorting and see how it works for us.
Change-Id: Iabf4adb3ade3b7835b35818b58855720363c2bf5
Otherwise projects loop in 'update_info' function
returns immediately during the very first call and
no data shown on page for another 30 seconds
Change-Id: Ic94894dcace48b3c1dc0bf01759b5088ca3cea37
With current timer setup the first load happens after 30 sec only and
all this time empty data is shown on panel.
Change-Id: I9200460b74b4d3323316da1406991e1ad768c57a
While working on the support for triggering $debian_release/master
branches (see previous commit) I noticed a bunch of missing or unclear
instructions as well as incomplete setup/configuration:
* Makefile: add missing `venv_dev` target to populate development
environment
* extend and clarify usage instructions in README.md
* dev environment: avoid having to manually configure ALLOWED_HOSTS,
instead identify hostname and listen on that (useful e.g.
when running the environment inside docker and then accessing
it via the docker IP like http://172.17.0.3:8000/release_panel/)
* Dockerfile: add python3-virtualenv + virtualenv as they are
needed for the venv handling, also install sqlite3 for
handling the sqlite database manually
* pin pylint to version 1.9.3[1]
[1] We need to pin pylint to version 1.9.3, which is the last
working version for us. Newer version of pylint (2.0.0 and up to
2.1.1) fail for us with:
| Executing django_jenkins.tasks.run_pylint...
| Traceback (most recent call last):
| File "./manage.py", line 10, in <module>
| execute_from_command_line(sys.argv)
| File "/usr/local/lib/python3.5/dist-packages/django/core/management/__init__.py", line 363, in execute_from_command_line
| utility.execute()
| File "/usr/local/lib/python3.5/dist-packages/django/core/management/__init__.py", line 355, in execute
| self.fetch_command(subcommand).run_from_argv(self.argv)
| File "/usr/local/lib/python3.5/dist-packages/django_jenkins/management/commands/jenkins.py", line 47, in run_from_argv
| super(Command, self).run_from_argv(argv)
| File "/usr/local/lib/python3.5/dist-packages/django/core/management/commands/test.py", line 29, in run_from_argv
| super(Command, self).run_from_argv(argv)
| File "/usr/local/lib/python3.5/dist-packages/django/core/management/base.py", line 283, in run_from_argv
| self.execute(*args, **cmd_options)
| File "/usr/local/lib/python3.5/dist-packages/django/core/management/base.py", line 330, in execute
| output = self.handle(*args, **options)
| File "/usr/local/lib/python3.5/dist-packages/django_jenkins/management/commands/jenkins.py", line 116, in handle
| coverage.save(tested_locations, options)
| File "/usr/local/lib/python3.5/dist-packages/django_jenkins/tasks/run_pylint.py", line 44, in run
| lint.Run(args, reporter=ParseableTextReporter(output=output), exit=False)
| TypeError: __init__() got an unexpected keyword argument 'exit'
This needs further investigation, though independent of this change.
It didn't hit us so far as our repoapi docker image isn't rebuilt
regularly and all previous builds, until this commit - which refreshes
the Dockerfile and we therefore get newer python modules - use older
python modules, including an older pylint version.
Change-Id: I35c5edb22642851f0b9b20d1b8a1c91fd24e6ac1
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
Victor Seva
Guillem Jover
Alexander Lutay
dependabot[bot]
Sergii Kipot
Michael Prokop
Robert Axelsen