JEDI integration test: clang

Ran 2681 tests. Observed 2680 passing
tests and 1 tests not passing.

• CDash results for test
• Build log (available after job completes)
• CI Job (requires AWS login)
• CI Job logs (requires AWS login)

Failures

fv3jedi_test_tier1_linearization_error................................................failed

CI System Information

Quick reference

Presubmit tests can be controlled by single-line annotations in the pull
request description. These annotations will be re-examined for each run.
Here is an example of their use:

# Build tests with other unsubmitted packages.
build-group=https://github.com/JCSDA-internal/oops/pull/2284
build-group=https://github.com/JCSDA-internal/saber/pull/651

# Disable the build-cache for tests.
jedi-ci-build-cache=skip

Each configuration setting must be on a single line, but order and
position does not matter.

# Enable tests for your draft PR (disabled by default).
run-ci-on-draft=true

# Select the compiler used by CI (defaults to random choice).
jedi-ci-test-select=gnu

# Select the jedi-bundle branch used for building. Using this option
# disables the build cache.
jedi-ci-bundle-branch=feature/my-bundle-change

Specifying a Build Group

In the default configuration the CI system will build candidate code against
the latest submitted version each package of the jedi-bundle. A pull request
can be built against unsubmitted versions of specific packages by specifying
the version using a tag in the pull request description. Multiple tags may
be added as long as each tag is on its own line of the pull request
description.

build-group=https://github.com/JCSDA-internal/oops/pull/2284

Build Cache

The CI system relies on a build cache to speed the the build process. Some
changes are capable of causing build failures arising from the use of the
cache. The CI system has two controls to modify cache behavior.

The build cache can be disabled by adding the annotation
jedi-ci-build-cache=skip to the PR description.

If it is necessary to rebuild the entire cache to remove a bug in the cached
binaries, add the annotation jedi-ci-build-cache=rebuild to the PR
description.

Selecting a Compiler

To save on cloud compute resources the CI test environment selects one of
our three environments randomly. If you want tests with a specific compiler
you can set the annotation jedi-ci-test-select to either gnu, intel,
or clang. Please do not use the special value all unless you have an
especially dangerous change known to affect all compilers or the CI
environment.

CI Development and Debug Options:

• jedi-ci-bundle-branch=branch-name: Unless otherwise specified tests
  will be run from the default branch of the jedi-bundle repository.
  This annotation overrides the branch and the value of this tag sets a
  valid branch name currently fetchable from the jedi-bundle repository
  that will be used for testing. If this annotation is explicitly set
  (even if set to the default branch), cache reading and writing is
  disabled and any cache annotations will be ignored.
• jedi-ci-next=true: This annotation will use the "next" tagged CI
  images. This tag will primarily be used by the infra team for testing
  spack-stack releases or breaking changes. At most times, the "next" tag
  will be assigned to the current live build images.
• jedi-ci-debug=true: This annotation can be used to induce a post-test
  delay of 60 minutes during which the build environment will be saved
  for inspection and debug activities.

FAQ

Q: Where did this test come from?

A: This is the new JEDI CI system whose code is hosted at
github.com/JCSDA-internal/CI.

Q: My draft pull request's tests are not running.

A: You must enable tests for draft PRs by adding the annotation
run-ci-on-draft=true in the pull request description.

Q: How can a test "pass with failures"?

A: Because the integration test is much larger than typical unit tests, a
small amount of flake test failure is allowed. Over time we will track
the repeatedly flaky tests and fix them. Please examine any failures
carefully to ensure that they were not caused by your change.

Q: Why can't I access the build log?

A: The AWS hosted build logs require a login to the jcsda-usaf AWS
account. We also provide a public build log available to anyone with the
link but this log file is not available until all tests are complete for
an environment.