The CentOS Project provides CI resources that are available to all CentOS and Fedora infra and infra related open source projects to come and consume. The aim is for projects to use this resource as a CI setup for themselves as well as to integrate against each other as the code base evolves.
- What is the goal of this effort.
What sort of help will the CentOS Project provide. (see https://docs.fedoraproject.org/en-US/cpe/day_to_day_centos/)
- Who can I speak with for more information. (#centos-ci on Freenode is where the CI team can be found)
Details on the hardware setup are at http://wiki.centos.org/QaWiki/PubHardware
We run Jenkins CI as our open-source continuous integration server. If you are not already familiar with it, you can read all about Jenkins CI at http://jenkins-ci.org/
Put all details relevant for the users here. There are two kinds of users, the people themselves and the projects that they run tests for.
Overall we have 2 types of user accounts: Project and Individual. Jenkins itself only knows about 'Project' accounts which are shared among the members of the project. Your individual account allows us to map your membership in each group, and control access.
Project admins and site admins can request an Individual jump host account, that allows them access to the Jenkins slave VM. All other users will only get a login and an API key that is tied down to their project. Users can setup jobs in the Jenkins interface but must ensure they lock the jobs down to their project slaves.
- Request a new job be added.
- Managing your jobs.
- Need a specific plugin to be installed.
- Checking worker machine status.
You can request your Individual jump host account by creating a ticket at https://bugs.centos.org (category: ci.centos.org), be sure to include:
- Your name
- Your SSH public key (which will be used to access the project account on the Jenkins slaves)
- The project you are working with
Your Individual jump host account gives you:
- SSH access to the project workspace (including all project credentials)
- SSH Access to provisioned worker nodes (through the project workspace)
Interface :: Duffy
/Duffy is our provisioning controller and management tool. It uses Ansible behind the hood to provision, manage and allocate machine resources in the test cluster. It presents a simple REST interface that can be called from the Jenkins VM and has an evolving set of API calls. Details of the API are listed on the /Duffy page.
- Logging into a worker node is possible. Machines that host a failed build will not be torn down, allowing developers to login and investigate. However, once this investigation is over, there is a manual process that needs to be run to re-provision the node.
- What is the longest machine lease I can get? It might be best to optimise the tests rather than optimise for machine time. However, if needed, we can provide persistent allocated machines dedicated to a role for 24/7 type operations if you can keep the nodes busy for 18 hours or more.
See the 'Artifacts' section on the /GettingStarted page