Skip to content

Commit

Permalink
Clean up outdated parts from README
Browse files Browse the repository at this point in the history
We have gotten rid of all PR testing except for packaging. That means we
don't really need to document GHPRB anymore.
  • Loading branch information
ekohl authored Jan 9, 2025
1 parent db061df commit d04de3d
Showing 1 changed file with 6 additions and 58 deletions.
64 changes: 6 additions & 58 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,9 @@
# Foreman's Jenkins Jobs

This repository contains all the job definitions and supporting code used in Jenkins jobs used by the Foreman project on it's own ci system [ci.theforeman.org](https://ci.theforeman.org) and [ci.centos.org](https://jenkins-foreman.apps.ocp.cloud.ci.centos.org/).

CentOS CI is used to provision VMs for end to end testing of installations.
We use Jenkins for our nightly and release package building.
Those are composed in packaging release pipelines and tested by calling out to CentOS CI to provision VMs for end to end testing of installations.
Then lastly there are jobs to deploy our website, our Jenkins configuration and our Puppet environment.

## Jenkins Job Builder

Expand All @@ -24,72 +25,19 @@ Useful resources:
| Nightly Source Builder | {git-repo}-{git-branch}-source-release | foreman-develop-source-release | hammer-cli-katello-master-source-release |
| Nightly Package Builder | {git-repo}-{git-branch}-package-release | foreman-develop-package-release | hammer-cli-katello-master-package-release |
| CI pipeline | {repository}-{environment}-{optional-concern}-pipeline | foreman-nightly-rpm-pipeline | foreman-nightly-deb-pipeline |
| Pull Request testing | {git-repo}-{optional-concern}-pr-test | katello-pr-test | foreman-packaging-rpm-pr-test |
| Pull Request testing | {git-repo}-{optional-concern}-pr-test | foreman-packaging-rpm-pr-test | foreman-packaging-deb-pr-test |
| Branch testing | {git-repo}-{git-branch}-test | foreman-3.5-stable-test | smart-proxy-3.5-stable-test |

## Job configurations

### Testing develop

All repos with an associated job that tests their master/develop branch should have a hook added to the repo to trigger immediate builds.

To set up the hook, an org/repo admin must:

* View the repository settings
* Click *Webhooks*
* Click *Add webhook*
* Payload URL: https://ci.theforeman.org/github-webhook/
* Content Type: application/json (default)
* Secret: add from secret store
* Just the push event

### Pull request testing

Core Foreman projects have GitHub pull requests tested on our Jenkins instance so it's identical to the way we test the primary development branches themselves. Simpler and quieter projects (such as installer modules) can use Github Actions instead. There is no obligation for Foreman projects to use Jenkins.

Every project that needs PR testing has at least two Jenkins jobs. Taking core Foreman as an example:

* Test job for the main development branch (develop or master): [test_develop](https://ci.theforeman.org/job/test_develop/)
* Test job for each PR: [test_develop_pr_core](https://ci.theforeman.org/job/test_develop_pr_core/)

#### Github Pull Request Builder

The GHPRB plugin uses webhooks installed on the repo to trigger a build, then it runs any job configured with the GHPRB trigger and a matching GitHub project set.

The plugin tests the latest commit on the PR branch only, it does not merge the PR with the base branch. The webhook may also trigger multiple jobs, and jobs may use different GitHub commit status names to easily test and report status on different types of tests.

PR jobs should be set up identically to primary branch tests, except for the SCM (which checks out `${sha1}`) and to add the GHPRB trigger (see the `github_pr` macro in JJB).

To set up the hook, an org/repo admin goes to the repository settings, then Webhooks & Services and adds a webhook with these settings:

* Payload URL: `https://ci.theforeman.org/ghprbhook/`
* Content type: `application/json`
* Secret: _redacted_
* Events: _Let me select individual events_, _Pull request_, _Issue comment_

An org admin must then change the org teams:

* Add the repository to the [Bots team](https://github.com/orgs/theforeman/teams/bots/repositories) with **write** access

## Quick reference for maintainers

Current PR test jobs (used on Foreman itself) support these commands:

* `ok to test` - run tests for an unknown user, if the code within the patch is not malicious
* `[test STATUS-NAME]`, e.g. `[test foreman]` to re-run a particular set of tests

# Foreman's Other Tests

Jenkins is not the only place tests are defined and executed.

## GitHub Actions

Several repositories use [GitHub Actions](https://github.com/features/actions) either *instead of* or *together with* Jenkins.
They commonly use our [reusable actions](https://github.com/theforeman/actions).

Repositories use [GitHub Actions](https://github.com/features/actions) and preferably our [reusable actions](https://github.com/theforeman/actions).
The definitions of these jobs are in `.github/workflows/` of their respective repositories.

Failed jobs cannot be re-triggered with a comment, only from the GitHub UI which requires maintainer permissions for the repository.
Failed jobs can be re-triggered from the GitHub UI which requires maintainer permissions for the repository.

## Packit

Expand Down

0 comments on commit d04de3d

Please sign in to comment.