(from slide 7 https://www.slideshare.net/opennebula/opennebulaconf2015-112-the-status-of-devuan-project-alberto-zuin)
## Ralph: I think it would help if

  • a) the arrows in the image were labelled
  • b) it separated the people/user roles from the packages and logs
  • c) identified the roles for all transitions

## end Ralph

Different components:

  • gdo
  • Jenkins
  • Amprolla
  • The communication between the components itself:
    • Releasebot (gdo –> Jenkins)

## Ralph: where is bugs.devuan.org? and roles re it?

gdo (GitLab/GL)

gdo is currently functioning as:

  1. VCS hosting (git)
  2. Authentication source
  3. Authorisation source

## Ralph: what about gdo issues?
## Ralph: what about gdo wiki?

TODO / Wishlist

  1. move authentication/authorisation to a dedicated service
  2. use webhooks for triggering
  3. move to a lighter weight git repo service

## Ralph: - well documented organizational structure wrt authorization


(this section is based on code audit of releasebot by evilham)


GROUP: git.devuan.org/$GROUP/$REPO
PERMISSIONS: nomenclature amd:msb

  • 1st half Add, Modify, Delete: permission on job associated with a repository
  • 2nd half Master, Security, Build suite: permission to build branches in each repository
    • Here Master refers to “master”, “Security” to “-security” and “Build suite” to “suites/” branches.

Any entity starts with permissions ---:---; permissions are additive on these criteria:

  • MEMBERS GROUP: 'cfg.get(“jobs”, “members_projectid”)' –> /devuan/devuan-repository-masters
    • Being member with master permissions adds amd:m-b permissions on all repositories
  • SECURITY GROUP: 'cfg.get(“jobs”, “security_projectid”)' –> ?
    • Being member adds ---:-s- permissions on all repositories
  • MASTER+ (on a given REPO):
    • Having these privileges adds ---:--b permissions on a given REPO

Permissions audit

(so-called security group is still unknown. Does not exist?)

Issuing a build (no pun intended)

  • A GROUP is enabled in releasebot's config file
  • A MEMBERS GROUP entity creates a GitLab Issue(*) “buildadd” for REPO
    • It is possible to “buildadd/modify/del” repositories that cannot be built (whose GROUP is not enabled)
    • “build” commands can only be executed against repositories whose GROUP is enabled
  • A MASTER+ entity on REPO creates a GitLab Issue(*) “build” for REPO
    • Issues must be assigned to autobuild and the labels correspond to the architecture
    • Labels can also be used to setup the build (sequential, pbuilder_network, …)

Builds can also be manually triggered on jenkins / the jenkins machine by *selected few*

  • (this could be rectified by m)

Release bot is run by a cron job every 5 minutes checking for issues reported to “autobuild”, checks permissions based on the reporter and hooks that with jenkins.

  • There are no error checks in the gitlab or jenkins integration libraries:
    • if jenkins fails to respond the script reports a job not found error
    • if gitlab fails there is a deafening silence …typically happens once every couple of months.
  • If the job doesn't exist in jenkins or a command is not recognized, an appropriate response is reported back to the originating issue and the issue is closed.

The jenkins jobs are created using xml templates found in jenkins\_tpl, one template each for source, binary, and repo jobs. For buildadd and buildmodify commands, Releasebot uses the templates to create each job by submit

Actual build job

Release bot passes info to jenkins, where each job is handled by jenkins-debian-glue
“various bits of script provided via jenkins-debian-glue that do the actual work of building sources and packages.”
“The built packages are deployed to the respective repo in the repo job that has a script that signs and uploads the files to dak and then tells dak to get to work.”
jenkins-debian-glue and jenkins-debian-glue-buildenv and jenkins-debian-glue-buildenv provide various hooks used during the builds.



TODO / Wishlist

Authentication system

If we are interested in building a federated authentication system that must be considered on a project wide scope not just at a build system scope, otherwise we get 2 or more separate authentication systems, each with their own risks & weaknesses.

More accountability (and accessiblity) for permissions:

  • The way we administer the permissions, the fact that there is no way of telling who has permissions to do what is an issue (quickly, without checking all repos)
  • Giving permissions should be practical and not discourage secure values