PRJenkins

Interacting with CI from a PR

All checks are automatically triggered when you push a commit (or commits) to a PR.

Where CI is run

Note that the Open MPI community CI testing is split across three pools:

1. Jenkins: recognizes bot: commands (see below).
2. Azure Pipelines: recognizes /azp commands (see the Azure docs for a full list, but you usually just need /azp run).
3. GitHub Actions: does not (yet?) recognize text commands.

Triggering a retesting by all or a subset of CI

Add one of these commands to a new comment on the PR. Testing should be retriggered shortly (some sites have a few minute delay in polling).

• All Jenkins CI tests: bot:retest
• All Azure Pipeline CI tests: /azp run (Including Mellanox)
• Git commit checker can be re-triggered in a few ways:
  • Edit the PR description (even just putting in an additional newline will work), or:
  • Click the "Actions" tab on the PR, and click the "Re-run jobs" button on the right-hand side of the page
• Open MPI Pull Request Build Checker: bot:aws:retest
• IBM: bot:ibm:retest (see section below for fine tuning)

Request that a PR be CI tested (Jenkins only)

To request that a PR not be CI tested add both of the following to the PR description (not a comment on the PR). This is useful when making documentation only changes (e.g., README)

• [skip ci]
• bot:notest

Not a Cherry-Pick

The git commit checker GitHub action is triggered for all release branches. One of its checks is for proper cherry-pick references to ensure proper tracking of commits across branches. However, sometimes we cannot cherry-pick a commit and need to identify the PR as "not a cherry-pick".

• bot:notacherrypick in your PR description

Handling the Allow list

If you see one of these comments on a PR (or similar from a CI Build Bot):

• Can one of the admins verify this patch?
• Can one of the admins or Open MPI members verify this patch? This means that the user submitting the PR is not a member of the GitHub Open MPI organization posted the PR.

Any member of the GitHub Open MPI organization can cause the test to run by adding a comment to the PR. However there are some options here.

Option 1: Run a one time test of the PR

Safest option. Only tests the current state at the time of the comment.

Add either of the following to a comment on the PR:

• bot:retest
• test this please

Option 2: Run tests for the life of the pull request

Test the current state and any time this PR is updated.

Add the following to a comment on the PR:

• ok to test

Option 3: Add the author to a allowlist of users

For the current PR and future PRs. This user can post/update PRs and will be treated as if they are a whitelisted member of the GitHub Open MPI group.

Add the following to a comment on the PR:

• add to whitelist

IBM CI Fine Tuning

• bot:ibm:retest : Basic testing
  • Triggers a parallel build with the following configurations:
    • GNU Compiler on 5 nodes (adjustable via bot:ibm:nodes:#:test)
    • XL Compiler on 3 nodes
• bot:ibm:nodes:#:test : Increase the number of nodes used for GNU Compiler test
  • Must also specify bot:ibm:retest
  • Default: 5 nodes
  • Minmum: 1 node
  • Maximum: 128 nodes
• bot:ibm:ppn:#:test : Define the number of processes-per-node to use during testing
  • Must also specify bot:ibm:retest
  • Default: 4
  • Minmum: 1
  • Maximum: 20

Link to our sister project CI triggers

• OpenPMIx CI triggers
• PRRTE CI triggers