Skip to content

PRJenkins

Jump to bottom
Josh Hursey edited this page Jul 12, 2022 · 45 revisions

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

Clone this wiki locally