Ansible Guide
#############
-This guide documents the process to setup and manage a new ansible role.
+This guide documents the process to setup and manage a new Ansible role.
.. _ansible-roles:
Environment Overview
####################
-Projects coming to The Linux Foundation (LF) for Continuous Integregration (CI)
+Projects coming to The Linux Foundation (LF) for Continuous Integration (CI)
services are generally given a similar infrastructure to the rest of our other
projects unless there is a good reason to deviate from this configuration.
Long term storage of CI logs is not complete during this phase as the log
shipping mechanisms that we use for capturing the console logs require that the
CI infrastructure be open to the public. To improve the log storage, as well as
-avoid potential issues with licensing for JIRA and Confluence the recomendation
+avoid potential issues with licensing for JIRA and Confluence the recommendation
for projects is stay in pre-formation for as short a time as possible or if
possible, skip a restricted formation phased altogether.
Code contributed to a project as seed needs to meet the following criteria:
-#. The code must pass any required Intelectual Property Review (IPR) that is
+#. The code must pass any required Intellectual Property Review (IPR) that is
in use by the project
#. The code must pass any licensing requirements related to the licensing used
LF does not presently have, nor is it aware of, tooling that will allow us
to properly scan incoming repository histories to verify that they meet
this. Requiring a squash commit of seed code is the way that we can
- definitevly enforce this.
+ definitively enforce this.
Post-formation
==============
Using "heads" instead, will attempt to make the a push into the repository bypassing
Gerrit which can come in handy for some isolated cases (when having force push rights).
Another variable commonly used is "refs/changes/<gerrit-number>" which is an explicit
- way of making an update to an exisiting gerrit. In such case, is best to let gerrit handle
+ way of making an update to an existing gerrit. In such case, is best to let gerrit handle
this via Change-Id_ in the commit text.
More options for this command: `git-push <https://git-scm.com/docs/git-push>`_.
#. Note down the image name from the packer build as we will need it later
#. Navigate to ``https://jenkins.example.org/credentials/store/system/domain/_/newCredentials``
-#. Configure the openstack cloud credential as follows:
+#. Configure the OpenStack cloud credential as follows:
.. code-block:: none
Nexus
#####
-Nexus is an antifact repository typically used in Java / Maven projects.
+Nexus is an artifact repository typically used in Java / Maven projects.
Stores Project artifacts, Javadocs, and Jenkins job logs.
.. _nexus-file-system:
We use OpenStack as our primary underlying cloud for CI. With the majority of
the projects all hosted with the same vendor we can adopt common management
-pratices across them.
+practices across them.
Sharing instance images
=======================
To access the Jenkins Production URL for any project use:
``https://jenkins.example.org``
-Similarily, the project's corresponding Jenkins Sandbox URL would be:
+Similarly, the project's corresponding Jenkins Sandbox URL would be:
``https://jenkins.example.org/sandbox``
Any users with an LFID can access the Jenkins Production site, but for Jenkins
server. Instead, we encourage them to use the Jenkins Sandbox.
The Jenkins Sandbox has similar configuration to the production instance.
-Jenkins Sandbos does not publish artifacts in Nexus or Nexus3 or vote in Gerrit which
+Jenkins Sandbox does not publish artifacts in Nexus or Nexus3 or vote in Gerrit which
makes it a safe environment to test the jobs. Users can edit and trigger the jobs
-directly to test the behaviour.
+directly to test the behavior.
The Jenkins Sandbox can contain dummy configuration files and dummy credentials in
case it helps take the test further and not fail on the first steps due to the configuration
not being present. Any attempt to actually use the configuration files in order
-to make any server comunications will fail. To add dummy configuration files, please
+to make any server communications will fail. To add dummy configuration files, please
create a new ticket to :ref:`Helpdesk <lfdocs-helpdesk>`.
In such case, merge jobs, push, CLM, Docker or Sonar jobs get tested to some extent due
to this limitation. Once the job template gets merged and becomes available in Jenkins Production,
-we can confirm the jobs are actually making server comunications as expected with Nexus-IQ,
+we can confirm the jobs are actually making server communications as expected with Nexus-IQ,
Sonar, Gerrit or Nexus.
The Sandbox has limited amount of Virtual Machine nodes instances
Code Review / releng / docs.git / commitdiff