Skip to content

PRJenkins

Jump to bottom
Jeff Squyres edited this page Oct 29, 2020 · 45 revisions

Interacting with Jenkins CI from a PR

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

  • Jenkins
  • Azure Pipelines

Our Jenkins instances recognize the bot: commands listed below. The Azure Pipelines instances do not recognize the bot: commands, and instead require /azp 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
  • Open MPI signed-off-by and email address checked: bot:commit:retest
  • Open MPI Pull Request Build Checker: bot:ompi: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
  • Mellanox: bot:mellanox: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

Handling the White 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 whitelist 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
Clone this wiki locally