* 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
The previous changes help with deleting some of the unused tags (roughly half of
the previous 30~40), but do not help in some cases and it's therefore impossible
to remove the remaining ones.
Currently, this is what happens:
a) repoapi retrieves this url for a project, e.g. for a tag in data-hal-jessie:
https://repoapi.mgm.sipwise.com/docker/tag/3534/ and uses tag.reference
gets the "reference" attribute:
sha256:fa18c06b84b17b19bed1d14b0b9d836bffba1531e68721dc8ad0a65cc7477761
b) manage_docker.sh (which works correctly) uses this complex command:
curl -vsiL -H "${curl_docker_header}" -X GET "${docker_url}/${docker_tag}" | sed -ne 's/^Docker-Content-Digest: \(sha256:[[[:alnum:]]\+\).*$/\1/ip;Tn;q;:n'
and with this input:
curl -vsiL -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' -X GET \
'https://docker.mgm.sipwise.com:5000/v2/data-hal-jessie/manifests/I30522e47cadb23b042e48f23b5a509dc9abf6ccb'
gets as reference:
sha256:ebc37e95c8844d37ec174d6208f80d664a5d099802d839cde0a4f74424d317fe
c) from stackoverflow in
https://stackoverflow.com/questions/38795240/delete-image-from-docker-registry-v2
it is suggested to take json.config.digest of the output of the url above (instead
of headers, like manage_docker.sh), and that is:
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 4915,
"digest": "sha256:fac5e71f2f690379d5fad98c550cb451a8c5197f529e519adaab7a66cef00019"
},
which is again different from both values above.
So this change adds code to remove in a way that mimics case b), in addition to
the existing one, in another attempt to completely fix the issue.
(It is not very elegant and it would be nice to pinpoint the exact problem
without these trial and error cycles by pushing to production, but it's
difficult when it depends on a running environment and the tools are not well
known to us, e.g. Django.)
Change-Id: I46859e369f039fffa3e191afb92c60df77d7e6e5
Commit 39744330b3 wrongly added code to call
request.delete() with more than one argument:
response = requests.delete(url, headers)
TypeError: delete() takes 1 positional argument but 2 were given
Change-Id: I65b82d9ccef33b295d009b00461f9eeca2da0827
Attempt to fix problem when release panel triggers jenkins jobs
setting branch=none when tag=mrX.X.X.1, when the branch parameter
should have branch=mrX.X.X
A change from string.join() to "".join() is needed for Python 3.
Change-Id: I89f7bb304180880bc7317b61aa675b8d2162f091
Attempt to fix problem when release panel triggers jenkins jobs
setting branch=none when tag=mrX.X.X.1, when the branch parameter
should have branch=mrX.X.X
This fix is basically the same as the one applied a few days ago in
4f4c28d92d for the file
(top)/build/utils.py which seems similar in purpose, I am not sure why
the duplicity, but this one seems to be the file mapped for the url
".../release_panel/build".
Change-Id: I04217f7f0d4a26802e4c3b808ef9732485d27edb
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
Updates:
* Debian jessie->stretch (to use current stable Debian version)
* Python 2.7->3.5 (since Python v2 won't be supported with the
next Django LTS version any longer and we want to be prepared)
* Improve uwsgi configuration for production usage while at it
(thanks Florian Apolloner for feedback and suggestions)
Necessary changes:
* Debian:
- we need to use uwsgi-plugin-python3 for Python3 support
- replace python-dev with python3-dev for Python3 support
and python with python3 accordingly
- get rid of __pycache__ directories to avoid inclusion in
resulting Debian package
* uwsgi:
- if we hardcode python34 (for jessie) or python35 (for stretch)
then we can't run uwsgi on all supported systems, so instead
try `plugin = python3` and rely on update-alternatives mechanism
of uwsgi-plugin-python3 Debian package to get it right for,
if that shouldn't work as needed then we can look into
/usr/share/python3/runtime.d/uwsgi-plugin-python3.rtupdate
or shipping repoapi.ini via puppet instead
* docker:
- python-distribute is not needed (anymore)
- adjust package names for Python3 usage, support jessie
and stretch at the same time
- note: just replacing 'stretch' with 'jessie' in t/Dockerfile
is enough to get a working repoapi docker image based on jessie
* Python3:
- assertItemsEqual became assertCountEqual
- mocking: `__builtin__.open` became `builtins.open`, see
https://stackoverflow.com/questions/1289894/how-do-i-mock-an-open-used-in-a-with-statement-using-the-mock-framework-in-pyth
- we need six >=1.9.0 for raise_from astraction in py3
Otherwise we're failing on Debian/jessie with:
| AttributeError: 'module' object has no attribute 'raise_from'
See https://github.com/benjaminp/six/blob/master/CHANGES
- assert_has_calls changes, fixes:
| AssertionError: Calls not found.
| Expected: [call('345', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered'),
| call('123', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered')]
| Actual: [call('123', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered'),
| call('345', 'hotfix fake.git 3.8.7.4+0~mr3.8.7.4 triggered')]
See https://docs.python.org/dev/library/unittest.mock.html#unittest.mock.Mock.assert_has_calls
- urllib:
- `from urlparse import urlparse` became `from urllib.parse import urlparse`
- `urllib.quote` became `urllib.parse.quote`
- configparser:
- `from ConfigParser import ...` became `from configparser import ...`
* Django:
- 'from views import ...' became 'from .views import ...'
- the "TEMPLATE_DIRS" setting needs to go into "TEMPLATES = [ { 'DIRS': [ ...."
nowadays, see https://docs.djangoproject.com/en/1.11/ref/templates/upgrading/
* celery:
- to use latest celery version 4 django-celery needs to be replaced
by django-celery-beat + django-celery-results
(otherwise we're running into https://github.com/celery/django-celery/issues/497),
see documentation at http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
- adjust systemd unit files to use ExecStart
| ExecStart=/var/lib/repoapi/venv_prod/bin/celery -A repoapi [...]
instead of
| ExecStart=/var/lib/repoapi/venv_prod/bin/python3 ./manage.py celery [...]
and use `--db=/var/lib/repoapi/flower` instead of
`--db=/var/lib/repoapi/flower.db` to avoid ending up with a file
named flower.db.db
Notes for migration (assuming root permissions):
- get rid of existing flower database (not containing relevant data):
mv /var/lib/repoapi/flower.db /var/lib/repoapi/flower.db.old
- re-deploy virtual environment from scratch:
mv /var/lib/repoapi/venv_prod /var/lib/repoapi/venv_prod.old
cd /usr/share/repoapi && make deploy
- service restarts (in case of virtual env changes):
systemctl restart nginx
systemctl restart repoapi-beat.service
systemctl restart repoapi-flower.service
systemctl restart repoapi-worker.service
systemctl restart uwsgi
- usage instructions for celery + django stuff:
/var/lib/repoapi/venv_prod/bin/celery flower --help
source /var/lib/repoapi/venv_prod/bin/activate && ./manage.py help --settings="repoapi.settings.prod"
- create superuser for django administration (https://repoapi*.mgm.sipwise.com/admin/):
source /var/lib/repoapi/venv_prod/bin/activate && ./manage.py createsuperuser --settings="repoapi.settings.prod"
Thanks: Victor Seva for assistance with porting
Change-Id: Iacb48bf5dadf4eae97b5fbe944e44370e525f64c
* 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
Sergii Kipot
Robert Axelsen
Manuel Montecelo