From 6bdbaa39c7f8cc955ceafa9b6859c15088fd3525 Mon Sep 17 00:00:00 2001 From: Adam Miller Date: Jul 20 2016 22:22:27 +0000 Subject: Add some info to the repo Signed-off-by: Adam Miller --- diff --git a/README.md b/README.md deleted file mode 100644 index f534677..0000000 --- a/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# releng-automation - -Automation Workflow Tooling for Fedora Release Engineering \ No newline at end of file diff --git a/README.rst b/README.rst new file mode 100644 index 0000000..ccdaf86 --- /dev/null +++ b/README.rst @@ -0,0 +1,145 @@ +============================== +Release Engineering Automation +============================== + +This is the `Fedora Release Engineering`_ repository for Automation Workflow +Tooling here. + +One of the primary goals of the Fedora Release Engineering Team moving forward +into the future is to continue to automate more and more components of the +process that actually creates Fedora, and to do so in a way that is maintainable +and can be collaborated upon. This repository is meant to be the focal point of +that effort. + +Release Engineering Automation Workflow +======================================= + +This effort has been put together by the collaboration of many involved in +Fedora and the original public write up of this effort and future goals was the +`Release Engineering Automation Workflow Engine`_. The pertinant details the +original proposal that have lived on are were iterated upon are now in this +repository. + +Currently the goal is to automate or make self-service options for as much as +humanly possible within the Fedora RelEng group using `Ansible`_. The technical +implementation of how this is being accomplished can be seen below. + +Technical Implementation +------------------------ + +Everything will be powered by `Ansible`_ as this is a toolchain that both Fedora +Infrastucture and Fedora Release Engineering is familiar with and has been using +heavily for automation tasks. We are simply aiming to solve a new automation +problem space with the same tool and a different set of rules/policy. + +Tasks or sets of tasks should be in an "Include Playbook" such that they are not +meant to stand on their own but should be included by other Playbooks or an +`Ansible Role`_. + +Workflow Playbooks should effectively be "glue" that supply necessary variables +to make the "Include Playbooks" and Roles useful for the Workflow at hand. + +Execution +--------- + +In the past (or still currently, depending on the specific task and state of +migration to the new workflow) Fedora Release Engineering Automation tasks are +performed by various scripts run on various machines within the Fedora +Infrastructure with no real centralized logging. Some of these are automated by +chron jobs and some run by hand by request of various members within the Fedora +Community, normally around Fedora Test Days. Finding information about old tasks +is not always the easiest of things to do and the delegation of tasks is +currently not available. The goal here is to provide a solution that removes +those barriers. + +Workflows will be executed and potentially orchestrate actions between multiple +other systems or tools such as bodhi, pungi, and koji. Fedmsgs will be emitted +with information about the start and completion of workflows along with metadata +about them. + +In the event of a compose, certain fedmsg output will be picked up by taskotron +and autocloud to perform various levels of testing. + +:: + + +--------------+ +----------------+ + | | +------------+ | | + | AutoCloud |<--------------+ +----------->+ Taskotron | + | | | fedmsg | | | + | +-------------->| |<-----------+ | + +--------------+ | | +----------------+ + +----+-------+ + | ^ + | | + | | + | | + | | + | | + V | + +------------------+-----------------+ + | | + | Release Engineering +-----------+ + | Workflow Automation Engine | | + | (loopabull) | | + | | | + +------------------+-----------------+ | + | | | + | | | + +-----------------+ | | + | | | + | | | + V V | + +-------------+ +--------------+ | + | | | | | + | bodhi | | | | + | | | pungi | | + +-------------+ | | | + | | | + +----------+---+ | + ^ | V + | | +---------------+ + | | | | + | +----------->| koji | + | | | + +------------------+ | + +---------------+ + +Licensing +========= + +Everything is copyrighted by the respective authors. You can use and +redistribute the code under the terms of version 3 or later of the GNU Public +License as published by the Free Software Foundation. + +To make licensing easier, license headers in the source files will be a single +line reference to Unique License Identifiers as defined by the Linux +Foundation's `SPDX`_ project. For example, in a source file the full "GPL v3.0 +or later" header text will be replaced by a single line: + +:: + + SPDX-License-Identifier: GPL-3.0+ + +The license terms of all files in the source tree should be defined by such +License Identifiers; in no case a file can contain more than one such License +Identifier list. + +If a ``SPDX-License-Identifier:`` line references more than one Unique License +Identifier, then this means that the respective file can be used under the terms +of either of these licenses, i. e. with + +:: + + SPDX-License-Identifier: GPL-3.0+ LGPL-3.1+ + +you can chose between GPL-2.0+ and LGPL-2.1+ licensing. + +We use the `SPDX Unique License Identifiers`_ here; + +.. _SPDX: http://spdx.org/ +.. _Ansible: https://github.com/ansible/ansible +.. _Ansible Role: http://docs.ansible.com/ansible/playbooks_roles.html#roles +.. _Fedora Release Engineering: https://pagure.io/releng +.. _SPDX Unique License Identifiers: http://spdx.org/licenses/ +.. _Release Engineering Automation Workflow Engine: + https://fedoraproject.org/wiki/Changes/ReleaseEngineeringAutomationWorkflowEngine