CI documentation
- added test host names - added simple deployment procedure script - fixed https support for swarm connection - added generic node deployment explanation - separated overview and third_part Change-Id: I087970f44c4bfd3f9a1d3106432e0868bc209138
This commit is contained in:
parent
afbcea1d49
commit
ba808f2fb7
190
docs/ci/overview.rst
Normal file
190
docs/ci/overview.rst
Normal file
@ -0,0 +1,190 @@
|
|||||||
|
Fuel Infrastructure
|
||||||
|
===================
|
||||||
|
|
||||||
|
Overview
|
||||||
|
--------
|
||||||
|
|
||||||
|
Fuel Infrastructure is the set of systems (servers and services) which provide
|
||||||
|
the following functionality:
|
||||||
|
|
||||||
|
* automatic tests for every patchset commited to Fuel Gerrit repositories,
|
||||||
|
* Fuel nightly builds,
|
||||||
|
* regular integration tests,
|
||||||
|
* custom builds and custom tests,
|
||||||
|
* release management and publishing,
|
||||||
|
* small helper subsystems like common ZNC-bouncer, status pages and so on.
|
||||||
|
|
||||||
|
Fuel Infrastructure servers are managed by Puppet from one Puppet Master node.
|
||||||
|
|
||||||
|
To add new server to the infrastructure you can either take any server with base
|
||||||
|
Ubuntu 14.04 installed and connect it to the Puppet Master via puppet agent, or
|
||||||
|
you can first set up the PXE-server with PXETool :ref:`pxe-tool` and then run server
|
||||||
|
provisioning in automated way.
|
||||||
|
|
||||||
|
Puppet
|
||||||
|
------
|
||||||
|
|
||||||
|
.. _pxe-tool:
|
||||||
|
|
||||||
|
Puppet Master
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
|
||||||
|
Puppet deployment with Fuel Infra manifests requires Puppet Master.
|
||||||
|
To install Puppet Master to the brand new server:
|
||||||
|
|
||||||
|
#. Get required repository with Puppet configuration:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
git clone ssh://(gerrit_user_name)@review.fuel-infra.org:29418/fuel-infra/puppet-manifests
|
||||||
|
|
||||||
|
#. Create a script to update puppet server to current version:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
#!/bin/bash
|
||||||
|
|
||||||
|
REPO='/home/user/puppet-manifests'
|
||||||
|
SERVER='pxetool'
|
||||||
|
# sync repo files
|
||||||
|
rsync -av --delete $REPO/modules/ root@$SERVER:/etc/puppet/modules/
|
||||||
|
rsync -av --delete $REPO/manifests/ root@$SERVER:/etc/puppet/manifests/
|
||||||
|
rsync -av --delete $REPO/bin/ root@$SERVER:/etc/puppet/bin/
|
||||||
|
rsync -av --delete $REPO/hiera/ root@$SERVER:/etc/puppet/hiera/
|
||||||
|
# create symlinks
|
||||||
|
ssh root@$SERVER ln -s /etc/puppet/hiera/common-example.yaml /var/lib/hiera/common.yaml 2> /dev/null
|
||||||
|
|
||||||
|
#. Install base Ubuntu 14.04 with SSH server running (set hostname to pxetool.test.local).
|
||||||
|
Download and install Puppet Agent package.
|
||||||
|
|
||||||
|
#. Run previously created script on your workstation to push configuration and scripts
|
||||||
|
to new server. Run /etc/puppet/bin/install_puppet_master.sh as root on new server.
|
||||||
|
|
||||||
|
The last script does the following:
|
||||||
|
|
||||||
|
* upgrades all packages on the system
|
||||||
|
* installs required modules
|
||||||
|
* installs puppet and Puppet Master packages
|
||||||
|
* runs puppet apply to setup Puppet Master
|
||||||
|
* runs puppet agent to do a second pass and verify installation is usable
|
||||||
|
|
||||||
|
.. note:: Puppet manifests take data (passwords, keys or configuration
|
||||||
|
parameters) from hiera configuration. To work with our predefined test data
|
||||||
|
script links ``hiera/common-example.yaml`` file to
|
||||||
|
``/var/lib/hiera/common.yaml``. This step must be done before running
|
||||||
|
``bin/install_puppet_master.sh``.
|
||||||
|
|
||||||
|
Once done, you can start deploying other nodes.
|
||||||
|
|
||||||
|
Nodes and Roles
|
||||||
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Currently, we define server roles via our hiera configuration (ssh://review.fuel-infra.org:29418/fuel-infra/puppet-manifests) using facter value ``ROLE``. Several roles are defined in ``hiera/roles``:
|
||||||
|
|
||||||
|
* anon_stat.yaml
|
||||||
|
* gerrit.yaml
|
||||||
|
* glusterfs_testing.yaml
|
||||||
|
* jenkins_master.yaml
|
||||||
|
* jenkins_slave.yaml
|
||||||
|
* lab.yaml
|
||||||
|
* mongo_testing.yaml
|
||||||
|
* nailgun_demo.yaml
|
||||||
|
* puppetmaster.yaml
|
||||||
|
* seed.yaml
|
||||||
|
* tools.yaml
|
||||||
|
* tracker.yaml
|
||||||
|
* web.yaml
|
||||||
|
* zbxproxy.yaml
|
||||||
|
* zbxserver.yaml
|
||||||
|
* znc.yaml
|
||||||
|
|
||||||
|
The most of roles are self explainable.
|
||||||
|
|
||||||
|
Generic Node Installation
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Follow these steps to deploy chosen node:
|
||||||
|
|
||||||
|
* install base Ubuntu 14.04
|
||||||
|
* install puppetlabs agent package
|
||||||
|
* append to ``/etc/hosts`` - ``<Puppet Master IP> puppet pxetool.test.local``
|
||||||
|
* run ``FACTER_ROLE=<role name> puppet agent --test`` to apply configuration
|
||||||
|
|
||||||
|
Jenkins
|
||||||
|
-------
|
||||||
|
|
||||||
|
Our Jenkins instances are configured to run in master-slave mode. We have
|
||||||
|
Jenkins master instance on a virtual machine and a number of hardware nodes
|
||||||
|
working as Jenkins slaves.
|
||||||
|
|
||||||
|
Jenkins slaves setup
|
||||||
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
There are several ways to setup Jenkins master-slave connection, and we use two
|
||||||
|
of them. The first one is organized simply by putting Jenkins master SSH-key in
|
||||||
|
authorized_keys file for jenkins user on a slave machine. Then you go to the
|
||||||
|
Jenkins Web UI and create node manually by specifying node IP address. Jenkins
|
||||||
|
master connects to the slave via SSH, downloads slave.jar file and runs jenkins
|
||||||
|
process on a slave.
|
||||||
|
|
||||||
|
The second approach requires more configuration steps to take, but allows you to
|
||||||
|
create slave node automatically from a slave node itself. To use it you need:
|
||||||
|
|
||||||
|
* install Swarm Plugin on Jenkins master
|
||||||
|
* create Jenkins user with ability to create nodes
|
||||||
|
* install jenkins-swarm-slave package on the slave
|
||||||
|
* configure the slave to use the mentioned Jenkins user
|
||||||
|
* run jenkins-swarm-slave service on the slave
|
||||||
|
|
||||||
|
Service will automatically connect to Jenkins master and create a node with proper
|
||||||
|
name and IP address.
|
||||||
|
|
||||||
|
Though this approach seems to be complicated, it is quite easy to implement it
|
||||||
|
with Puppet, as we do in jenkins::slave Puppet class (defined in
|
||||||
|
puppet-manifests/modules/jenkins/manifests/slave.pp).
|
||||||
|
|
||||||
|
If you use Gerrit slave with HTTPs support (default hiera value), please also
|
||||||
|
include jenkins::swarm_slave as it will trust Jenkins Master certificate on
|
||||||
|
Node side.
|
||||||
|
|
||||||
|
The downside of the swarm slave plugin is that every time you reboot Jenkins
|
||||||
|
master instance, slaves are recreated and, therefore, lose all the labels
|
||||||
|
assigned to them via Jenkins WebUI.
|
||||||
|
|
||||||
|
Gerrit
|
||||||
|
------
|
||||||
|
|
||||||
|
Although fuel-* repositories are hosted by the `OpenStack Gerrit <http://review.openstack.org>`_,
|
||||||
|
we use additional Gerrit instance to host OpenStack packages, internal projects and all the code
|
||||||
|
related to Infrastructure itself.
|
||||||
|
|
||||||
|
Our Gerrit instance is installed and configured by Puppet, including specifying
|
||||||
|
the exact Java WAR file that is used(link). To manage Gerrit instance we use
|
||||||
|
`Jeepyb <http://ci.openstack.org/jeepyb.html>`_ - the tool written by Openstack Infra
|
||||||
|
team, which allows to store projects configuration in YAML format.
|
||||||
|
|
||||||
|
To use Jeepyb with gerrit you need to create "projects.yaml" configuration file,
|
||||||
|
where for each project you add the following information:
|
||||||
|
|
||||||
|
* project name
|
||||||
|
* project description
|
||||||
|
* project ACL
|
||||||
|
* project upstream
|
||||||
|
|
||||||
|
If "upstream" option is specified, Jeepyb will automaticaly import the upstream
|
||||||
|
repository to this new project. To apply the configuration, use "manage-projects" command.
|
||||||
|
|
||||||
|
Every project has ACL file. One ACL file can be reused in several projects. In
|
||||||
|
ACL file, access rights are defined based on the Gerrit user groups.
|
||||||
|
For example, in this file you can allow certain group to use the Code-Review
|
||||||
|
+/-2 marks.
|
||||||
|
|
||||||
|
In our gerrit, we have some global projects - <projects>/. The Core Reviewers
|
||||||
|
for these projects are <one-core-group>.
|
||||||
|
|
||||||
|
Contributing
|
||||||
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Feedback
|
||||||
|
~~~~~~~~
|
310
docs/ci/third_party.rst
Normal file
310
docs/ci/third_party.rst
Normal file
@ -0,0 +1,310 @@
|
|||||||
|
.. _third-party-testing:
|
||||||
|
|
||||||
|
Third Party Testing
|
||||||
|
===================
|
||||||
|
|
||||||
|
Overview
|
||||||
|
--------
|
||||||
|
|
||||||
|
Gerrit has an event stream which can be subscribed to, using this it
|
||||||
|
is possible to test commits against testing systems beyond those
|
||||||
|
supplied by Fuel's Jenkins setup. It is also possible for these
|
||||||
|
systems to feed information back into Gerrit. What's more, they
|
||||||
|
can leave non-gating votes on Gerrit review requests.
|
||||||
|
|
||||||
|
There are several examples of systems that read the Gerrit event stream
|
||||||
|
and run their own tests on the commits
|
||||||
|
`on this page <https://wiki.openstack.org/wiki/ThirdPartySystems>`_.
|
||||||
|
For each patch set the third party system tests, the system adds a comment
|
||||||
|
in Gerrit with a summary of the test result and links to the test artifacts.
|
||||||
|
|
||||||
|
Requirements
|
||||||
|
------------
|
||||||
|
|
||||||
|
* Until a third party testing system operates in a stable fashion, third
|
||||||
|
party tests can comment on patches but not vote on them.
|
||||||
|
|
||||||
|
* A system can also be set up to only do '+1' reviews and leave all the
|
||||||
|
'-1's to be manually confirmed.
|
||||||
|
|
||||||
|
* A third-party system may only leave one comment per patch set
|
||||||
|
(unless it is retriggered).
|
||||||
|
|
||||||
|
* The maintainers are responsible for re-triggering tests when their third
|
||||||
|
party testing system breaks.
|
||||||
|
|
||||||
|
* Support recheck to request re-running a test.
|
||||||
|
|
||||||
|
* Support the following syntaxes: ``recheck``.
|
||||||
|
* Recheck means recheck everything. A single recheck comment should
|
||||||
|
re-trigger all testing systems.
|
||||||
|
|
||||||
|
* Publish contact information for the maintainers.
|
||||||
|
|
||||||
|
* All accounts must be previously set by posting launchpad bug to add your
|
||||||
|
system.
|
||||||
|
* Maintainers are encouraged to be in IRC regularly to make it
|
||||||
|
faster to contact them.
|
||||||
|
|
||||||
|
* Include a public link to all test artifacts to make debugging failed tests
|
||||||
|
easier (using a dns name over a hardcoded ip is recommended).
|
||||||
|
This should include:
|
||||||
|
|
||||||
|
* Environment details
|
||||||
|
|
||||||
|
* This must include a utc timestamp of the test run
|
||||||
|
* Test configuration
|
||||||
|
|
||||||
|
* Skipped tests
|
||||||
|
* logs should include a trace of the commands used
|
||||||
|
* OpenStack logs
|
||||||
|
* Tempest logs (including ``testr_results.html.gz``)
|
||||||
|
|
||||||
|
* logs must be browsable; logs requiring download, installation or login
|
||||||
|
to access are not acceptable
|
||||||
|
|
||||||
|
.. note:: All test artifacts must be retained for one month.
|
||||||
|
|
||||||
|
Reading the Event Stream
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
It is possible to use ssh to connect to ``review.fuel-infra.org`` on port 29418
|
||||||
|
with your ssh key if you have a normal reviewer account in Gerrit.
|
||||||
|
|
||||||
|
This will give you a real-time JSON stream of events happening inside Gerrit.
|
||||||
|
For example:
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
$ ssh -p 29418 USERNAME@review.fuel-infra.org gerrit stream-events
|
||||||
|
|
||||||
|
Will give a stream with an output like this (line breaks and
|
||||||
|
indentation added in this document for readability, the real JSON will
|
||||||
|
be all one line per event):
|
||||||
|
|
||||||
|
.. code-block:: javascript
|
||||||
|
|
||||||
|
{"type":"comment-added","change":
|
||||||
|
{"project":"openstack/keystone","branch":"stable/essex","topic":"bug/969088","id":"I18ae38af62b4c2b2423e20e436611fc30f844ae1","number":"7385","subject":"Make import_nova_auth only create roles which don\u0027t already exist","owner":
|
||||||
|
{"name":"Chuck Short","email":"chuck.short@canonical.com","username":"zulcss"},"url":"https://review.fuel-infra.org/7385"},
|
||||||
|
"patchSet":
|
||||||
|
{"number":"1","revision":"aff45d69a73033241531f5e3542a8d1782ddd859","ref":"refs/changes/85/7385/1","uploader":
|
||||||
|
{"name":"Chuck Short","email":"chuck.short@canonical.com","username":"zulcss"},
|
||||||
|
"createdOn":1337002189},
|
||||||
|
"author":
|
||||||
|
{"name":"Mark McLoughlin","email":"markmc@redhat.com","username":"markmc"},
|
||||||
|
"approvals":
|
||||||
|
[{"type":"CRVW","description":"Code Review","value":"2"},{"type":"APRV","description":"Approved","value":"0"}],
|
||||||
|
"comment":"Hmm, I actually thought this was in Essex already.\n\nIt\u0027s a pretty annoying little issue for folks migrating for nova auth. Fix is small and pretty safe. Good choice for backporting"}
|
||||||
|
|
||||||
|
For most purposes you will want to trigger on ``patchset-created`` for when a
|
||||||
|
new patchset has been uploaded.
|
||||||
|
|
||||||
|
Further documentation on how to use the events stream can be found in `Gerrit's stream event documentation page <http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-stream-events.html>`_.
|
||||||
|
|
||||||
|
Posting Result To Gerrit
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
External testing systems can give non-gating votes to Gerrit by means
|
||||||
|
of a -1/+1 verify vote. Comments should also be provided to explain what kind
|
||||||
|
of test failed. We do also ask that the comments contain public links to the
|
||||||
|
failure so that the developer can see what caused the failure.
|
||||||
|
|
||||||
|
An example of how to post this is as follows:
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
$ ssh -p 29418 USERNAME@review.fuel-infra.org gerrit review -m '"Test failed on MegaTestSystem <http://megatestsystem.org/tests/1234>"' --verified=-1 c0ff33
|
||||||
|
|
||||||
|
In this example ``c0ff33`` is the commit ID for the review. You can
|
||||||
|
set the verified to either `-1` or `+1` depending on whether or not it
|
||||||
|
passed the tests.
|
||||||
|
|
||||||
|
Further documentation on the `review` command in Gerrit can be found in the `Gerrit review documentation page <http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-review.html>`_.
|
||||||
|
|
||||||
|
We do suggest cautious testing of these systems and have a development Gerrit
|
||||||
|
setup to test on if required. In SmokeStack's case all failures are manually
|
||||||
|
reviewed before getting pushed to OpenStack, while this may not scale it is
|
||||||
|
advisable during the initial testing of the setup.
|
||||||
|
|
||||||
|
There are several triggers that gerrit will match to alter the
|
||||||
|
formatting of comments. The raw regular expressions can be seen in
|
||||||
|
`gerrit.pp <https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/gerrit.pp>`_.
|
||||||
|
For example, to have your test results formatted in the same manner as
|
||||||
|
the upstream Jenkins results, use a template for each result matching::
|
||||||
|
|
||||||
|
* test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some comment about the test
|
||||||
|
|
||||||
|
.. _request-account-label:
|
||||||
|
|
||||||
|
Creating a Service Account
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
In order to post comments as a Third Party CI System and eventually verify
|
||||||
|
your build status on Gerrit patches, you will need a dedicated Gerrit
|
||||||
|
CI account. You will need to create this account in our OpenID provider
|
||||||
|
`Launchpad <https://launchpad.net>`_. You may already have an existing
|
||||||
|
personal account in Launchpad, but you should create a new and entirely
|
||||||
|
separate account for this purpose.
|
||||||
|
|
||||||
|
Once you have created this account with the OpenID provider you can log
|
||||||
|
into Gerrit with that new account as you would with your normal user
|
||||||
|
account. Once logged in you will need to do several things:
|
||||||
|
|
||||||
|
1. Set an SSH username at https://review.fuel-infra.org/#/settings/ if
|
||||||
|
it isn't already set. This is the username your CI system will use to
|
||||||
|
SSH to Gerrit in order to read the event stream.
|
||||||
|
|
||||||
|
2. Set the account's fullname at https://review.fuel-infra.org/#/settings/contact
|
||||||
|
This name should follow a few rules in order to make it clear in Gerrit
|
||||||
|
comments what this CI system exists to test. The name should have three
|
||||||
|
pieces ``Organization`` ``Product/technology`` ``CI designator``. The
|
||||||
|
organization value should be your company name or other organization
|
||||||
|
affiliation. Product/technology should describe the product or technology
|
||||||
|
you are testing in conjunction with OpenStack. This should be the name of
|
||||||
|
a component which cannot be tested in the official OpenStack
|
||||||
|
infrastructure (requires particular physical hardware, proprietary
|
||||||
|
software, some hypervisor feature not available in public clouds,
|
||||||
|
et cetera). Note this should not be the name of an OpenStack project but
|
||||||
|
rather the thing you are testing with OpenStack projects. And finally
|
||||||
|
the CI designator is used to denote this is a CI system so that automatic
|
||||||
|
Gerrit comment parsers can filter these comments out. This value should
|
||||||
|
be ``CI`` for most CI systems but can be ``Bot`` if you are not
|
||||||
|
performing continuous integration. An example of a proper name would be
|
||||||
|
something like ``IBM DB2 CI``.
|
||||||
|
|
||||||
|
3. Add the SSH public key you will be using to the Gerrit account at
|
||||||
|
https://review.fuel-infra.org/#/settings/ssh-keys You can generate an
|
||||||
|
ssh key using ``ssh-keygen``. You want to give Gerrit the contents of
|
||||||
|
the generated id_rsa.pub file.
|
||||||
|
|
||||||
|
Once you have done this you will have everything you need to comment on
|
||||||
|
Gerrit changes from our CI system but you will not be able to vote +/-1
|
||||||
|
Verified on changes. To get voting rights you will need to get the release
|
||||||
|
group of the project you are testing to add you to their project specific
|
||||||
|
<project>-ci group. Please contact the project in question when you are
|
||||||
|
ready to start voting and they can add you to this group.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
The Jenkins Gerrit Trigger Plugin Way
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
There is a Gerrit Trigger plugin for Jenkins which automates all of the
|
||||||
|
processes described in this document. So if your testing system is Jenkins
|
||||||
|
based you can use it to simplify things. You will still need an account to do
|
||||||
|
this as described in the :ref:`request-account-label` section above.
|
||||||
|
|
||||||
|
The Gerrit Trigger plugin for Jenkins can be found on `the Jenkins
|
||||||
|
repository`_. You can install it using the Advanced tab in the
|
||||||
|
Jenkins Plugin Manager.
|
||||||
|
|
||||||
|
.. _the Jenkins repository: http://repo.jenkins-ci.org/repo/com/sonyericsson/hudson/plugins/gerrit/gerrit-trigger/
|
||||||
|
|
||||||
|
Once installed Jenkins will have a new `Gerrit Trigger` option in the `Manage
|
||||||
|
Jenkins` menu. This should be given the following options::
|
||||||
|
|
||||||
|
Hostname: review.fuel-infra.org
|
||||||
|
Frontend URL: https://review.fuel-infra.org/
|
||||||
|
SSH Port: 29418
|
||||||
|
Username: (the Gerrit user)
|
||||||
|
SSH Key File: (path to the user SSH key)
|
||||||
|
|
||||||
|
Verify
|
||||||
|
------
|
||||||
|
Started: 0
|
||||||
|
Successful: 1
|
||||||
|
Failed: -1
|
||||||
|
Unstable: 0
|
||||||
|
|
||||||
|
Code Review
|
||||||
|
-----------
|
||||||
|
Started: 0
|
||||||
|
Successful: 0
|
||||||
|
Failed: 0
|
||||||
|
Unstable: 0
|
||||||
|
|
||||||
|
(under Advanced Button):
|
||||||
|
|
||||||
|
Stated: (blank)
|
||||||
|
Successful: gerrit approve <CHANGE>,<PATCHSET> --message 'Build Successful <BUILDS_STATS>' --verified <VERIFIED> --code-review <CODE_REVIEW>
|
||||||
|
Failed: gerrit approve <CHANGE>,<PATCHSET> --message 'Build Failed <BUILDS_STATS>' --verified <VERIFIED> --code-review <CODE_REVIEW>
|
||||||
|
Unstable: gerrit approve <CHANGE>,<PATCHSET> --message 'Build Unstable <BUILDS_STATS>' --verified <VERIFIED> --code-review <CODE_REVIEW>
|
||||||
|
|
||||||
|
Note that it is useful to include something in the messages about what testing
|
||||||
|
system is supplying these messages.
|
||||||
|
|
||||||
|
When creating jobs in Jenkins you will have the option to add triggers. You
|
||||||
|
should configure as follows::
|
||||||
|
|
||||||
|
Trigger on Patchset Uploaded: ticked
|
||||||
|
(the rest unticked)
|
||||||
|
|
||||||
|
Type: Plain
|
||||||
|
Pattern: openstack/project-name (where project-name is the name of the project)
|
||||||
|
Branches:
|
||||||
|
Type: Path
|
||||||
|
Pattern: **
|
||||||
|
|
||||||
|
This job will now automatically trigger when a new patchset is
|
||||||
|
uploaded and will report the results to Gerrit automatically.
|
||||||
|
|
||||||
|
Testing your CI setup
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
You can use the ``fuel-external/test`` project to test your external CI
|
||||||
|
infrastructure with OpenStack's Gerrit. By using the sandbox project you
|
||||||
|
can test your CI system without affecting regular OpenStack reviews.
|
||||||
|
|
||||||
|
Once you confirm your CI system works as you expect, change your
|
||||||
|
configuration of the gerrit trigger plugin or zuul to subscribe to gerrit
|
||||||
|
events from your target project.
|
||||||
|
|
||||||
|
Permissions on your Third Party System
|
||||||
|
--------------------------------------
|
||||||
|
|
||||||
|
When you create your CI account it will have no special permissions.
|
||||||
|
This means it can comment on changes but generally not vote +/-1
|
||||||
|
Verified on any changes. The exception to this is on the
|
||||||
|
``fuel-external/test`` project. Any account is able to vote +/-1
|
||||||
|
Verified on that account and it provides a way to test your CI's voting
|
||||||
|
abilities before you vote on other projects.
|
||||||
|
|
||||||
|
.. _openstack-dev/ci-sandbox: https://review.fuel-infra.org/[ADDME]
|
||||||
|
|
||||||
|
The Fuel Infrastructure team disables mis-behaving third-party ci
|
||||||
|
accounts at its discretion. This documentation endeavours to outline specific
|
||||||
|
circumstances that may lead to an account being disabled. There have been
|
||||||
|
times when third-party ci systems behave in ways we didn't envision
|
||||||
|
and therefore were unable to document prior to the event. If your
|
||||||
|
third-party ci system has been disabled, please don't hesitate to contact
|
||||||
|
devops team.
|
||||||
|
|
||||||
|
In order to get your Third Pary CI account to have voting permissions on
|
||||||
|
repos in gerrit in addition to ``fuel-external/test`` you have a greater
|
||||||
|
chance of success if you follow these steps:
|
||||||
|
|
||||||
|
* Set up your system and test it according to "Testing your CI setup" outlined
|
||||||
|
above (this will create a history of activity associated with your account
|
||||||
|
which will be evaluated when you apply for voting permissions).
|
||||||
|
|
||||||
|
* Post comments, that adhere to the "Requirements" listed above, that
|
||||||
|
demonstrate the format for your system communication to the repos
|
||||||
|
you want your system to test.
|
||||||
|
|
||||||
|
* Once your Third Party Account has a history on gerrit so that others
|
||||||
|
can evaluate your format for comments, and the stability of your
|
||||||
|
voting pattern (in the sandbox repo):
|
||||||
|
|
||||||
|
* send an email to the fuel-devops mailing list nominating your
|
||||||
|
system for voting permissions
|
||||||
|
|
||||||
|
* fuel-devops@mirantis.com
|
||||||
|
|
||||||
|
* present your account history
|
||||||
|
* address any questions and concerns with your system
|
||||||
|
|
||||||
|
* If the members of the program you want voting permissions from agree
|
||||||
|
your system should be able to vote, the release group for that program
|
||||||
|
or project can add you to the <project>-ci group specific to that
|
||||||
|
program/project.
|
@ -11,3 +11,5 @@ Table of contents
|
|||||||
user
|
user
|
||||||
devops
|
devops
|
||||||
buildsystem
|
buildsystem
|
||||||
|
ci/overview
|
||||||
|
ci/third_party
|
||||||
|
Loading…
Reference in New Issue
Block a user