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
* We want to split build releases from hotfix perms
* create dev and devops groups and assign desired permissions.
These groups will match LDAP groups.
* create permissions using hack stolen from
https://stackoverflow.com/questions/29296757/django-data-migrate-permissions
Change-Id: I1b82ebf13aa3cba05e4733e4bef186fbbb52bb13
to be able to build mrX.Y as release-mrX.Y-update
we need to have a previous build. This tools allows
to create a fake build
* don't trigger old BuildRelease instance
* create_build_release() add fake option
Change-Id: I99293a1c41a567d920a086bcaec329defdcf235b
* 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
* using https://github.com/manosim/django-rest-framework-api-key
for Permissions. Will generate an Auth KEY for jenkins to be able
to trigger build from there using build REST API
* store the info needed to trigger builds for a set of projects for
a release
- build is a list of projects to be built with branch or tag as orig
and release as destination for a debian distribution
* added release_uuid to JenkinsJobInfo model
- release_uuid is the way to group project builds for a release
- tag works for group of jobs for a project
Change-Id: Iebeaa54308c3e569a167f55d98c184b52248af8a
Victor Seva