Skip to content

PRJenkins

Jump to bottom
Geoff Paulsen edited this page Oct 7, 2021 · 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
  • 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)
    • GNU only: bot:ibm:gnu:retest
    • PGI only: bot:ibm:pgi:retest
    • XL only: bot:ibm:xl:retest

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

IBM CI Compile and Run Triggers

  • IBM CI (GNU): bot:ibm:gnu:retest / bot:ibm:scale:retest
    • Retest GNU compiler
    • Compile and run test (functional level).
      • Default: 10 nodes (adjustable via bot:ibm:nodes:#:test)
    • Scale run option available
      • Default: Disabled, but can be enabled with adjustment options.
  • IBM CI (XL): bot:ibm:xl:retest
    • Retest IBM XL compiler
    • Compile and run test (functional level).
      • Default: 2 nodes (adjustable via bot:ibm:nodes:#:test)
    • Scale run - Disabled.
  • IBM CI (PGI): bot:ibm:pgi:retest
    • Retest PGI compiler
    • Compile and run test (functional level).
      • Default: 2 nodes (adjustable via bot:ibm:nodes:#:test)
    • Scale run - Disabled.

IBM CI Scale Testing Adjustment Triggers

Adjustment triggers for scale testing. Notice that they end with :test and not :retest. If you want to specify one of the below it must be in addition to the bot:ibm:gnu:retest trigger. For example:

bot:ibm:gnu:retest
bot:ibm:nodes:11:test
bot:ibm:scale:42:test
  • Functional Testing: bot:ibm:nodes:#:test
    • Number of "nodes" to use for functional testing.
    • Default: 10 nodes
    • Minmum: 1 node
    • Maximum: 37 nodes
  • Scale Testing (Default): bot:ibm:scale:test
    • Enable scale functional testing with default number of "nodes"
    • Default: 64 nodes
  • Scale Testing (Adjustable): bot:ibm:scale:#:test
    • Enable scale functional testing with the specified number of "nodes"
    • Default: 0 (disabled)
    • Minmum: 0 nodes (disabled)
      • Special Value of 0 to disable scale testing
    • Maximum: 160 nodes

Link to our sister project openpmix's CI triggers

Clone this wiki locally