Uploaded image for project: 'IT: Release Engineering'
  1. IT: Release Engineering
  2. RELENG-374

Self-Serv release PROCESS for projects (Target Q2 2019)

Issue XMLXMLWordPrintable

    • Self-serve release process for projects

      • This phase is for the PROCESS: Maven and containers (Docker) only

      There are more milestones and stories to be planned in relation to this Epic.
      Sigul in only one aspect of what will be required to complete this effort.

      • sigul does secure automated artifact signing enabling the ability to release artifacts to centralized repositories that have hard standards related to code and artifact signing

      https://lists.opendaylight.org/pipermail/dev/2017-August/003992.html

      Based on discussions on the OpenDaylight mailing list we need to think about how we can make releases more self serve for projects. RELENG-171 created a generic release job which allowed projects to create out of stream releases but they still need to pull in Helpdesk when they want to promote their release.

      From the mailing list discussions I think there's 3 things we need to improve for projects to be more self serve:

      1) Jenkins manual job triggering. It would be handy if they can trigger their own release job either through the Jenkins UI or through Gerrit. The problem with Jenkins though is giving a committer access means they can trigger any jobs not just their own and we have to play with Jenkins permissions.

      One idea which probably deserves an investigative Jira is parsing the GERRIT_EVENT_COMMENT_TEXT for a syntax we design. This way projects can pass variables into Jenkins using this syntax perhaps and manual trigger via Gerrit comment. Perhaps we can enforce permissions as well by having the jobs read a text file in the project repo containing a list of usernames that are allowed to trigger release builds.

      2) Gerrit permissions for PTL / Committers to block their stable branches during code freeze

      It isn't scalable for helpdesk to manage this if many projects will be doing their own out of stream releases

      3) Nexus permissions to promote own project staging repos

      This is more vague as I need to think about this more in case other permissions might be useful. However the main one is the ability for project committers to click the promote button for their own releases when it is ready to go. Today they need to raise a helpdesk ticket which won't scale if there were many projects doing independent releases.

      Note: This work likely will have more sub-tasks once we start figuring all this out.

      Maybe we can make a project that manages this via Gerrit somehow.

              Unassigned Unassigned
              zxiiro Thanh Ha
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: