* 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
* 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
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
In Python3 all strings are considered Unicode by default. The
unicode type from Python 2 is called str in Python 3, and str
becomes bytes. In Python3, there aren’t any automatic conversions
between str and bytes though. The json.loads in Python versions
>3 and <3.6 expects a string representation and not bytes. As we
receive bytes we need to decode() it, as this always returns str,
just as needed.
Fixes:
| File "./release_dashboard/views/build.py", line 59, in hotfix_build
| json_data = json.loads(request.body)
| File "/usr/lib/python3.4/json/__init__.py", line 312, in loads
| s.__class__.__name__))
| TypeError: the JSON object must be str, not 'bytes'
See https://docs.djangoproject.com/en/1.11/topics/python3/ and
https://vinta.ws/code/notes-of-porting-to-python-3-for-a-django-project.html
for related documentation.
Change-Id: I3984c5fd1f79b94680e680c8da64dd0ac111cbe9
* we need to use reference ( docker API it doesn't support tag name )
* fix tag date (value in the first occurrence not last)
Change-Id: I2fa2f7bedaca4cdeeb3a3a2d4a3f4a661d15fad1
* provide info of actual images and tags
* refresh docker images/tag via release_dashboard
* keep that info in db
* fix Dockerfile documentation
* cleanup thanks to flake8
Change-Id: I743482da9b4d50f7b1832cad324882f3a49cbcf0
Victor Seva
Michael Prokop