nvidia/skills · Official

mcore-testing

Test system for Megatron-LM. Covers test layout, recipe YAML structure, adding and running unit and functional tests, golden values, marker filters, and CI parity.

All-time #6878 First seen May 30, 2026
8-week activity · all time api

Installation

$ npx skills add nvidia/skills --skill mcore-testing

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from nvidia/skills · top by installs.

npx skills add nvidia/skills

Browse all from nvidia/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 3.2K
License LICENSE-APACHE
Default branch main
Open issues 5
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

LicenseApache-2.0
More metadata
author
Philip Petrakian <[email protected]>

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 7,443 B
  • docs SUMMARY.md 184 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1,747 installs

SKILL.md

Testing Guide


Answer-First Testing Facts

For questions about disabling tests without deleting them:

  • Functional recipe entries stay in YAML; disable by suffixing scope with

-broken, for example scope: [mr-github] -> scope: [mr-github-broken].

  • Unit-test skips use pytest markers instead: @pytest.mark.flakyindev skips

in the default dev environment, and @pytest.mark.flaky skips in LTS.

  • Do not delete the test case or recipe entry when the goal is discoverability

and easy re-enable.


Test Layout

tests/
├── unit_tests/          # pytest, 1 node × 8 GPUs, torch.distributed runner
├── functional_tests/    # end-to-end shell + training scripts
│   └── test_cases/
│       └── {model}/{test_case}/
│           ├── model_config.yaml          # training args
│           └── golden_values_{env}_{platform}.json
└── test_utils/
    ├── recipes/
    │   ├── h100/        # YAML recipes for H100 jobs
    │   └── gb200/       # YAML recipes for GB200 jobs
    └── python_scripts/  # helpers (recipe_parser, golden-value download, …)

How Tests Execute

The GitHub Actions runner invokes launchnemorun_workload.py, which uses nemo-run to launch a DockerExecutor container. The repo is bind-mounted at /opt/megatron-lm; training data is mounted at /mnt/artifacts.

Unit tests are dispatched through torch.distributed.run:

  • Ranks 0 and 3 are tee-d to stdout; all other ranks write only to log files.
  • Per-rank log files land at {assets_dir}/logs/1/ and are uploaded as a

GitHub artifact after the run.

Functional tests are driven by tests/functionaltests/shelltestutils/runci_test.sh. Only rank 0 runs the pytest validation step; training output from all ranks is uploaded as an artifact.

Flaky-failure auto-retry: launchnemorun_workload.py retries up to 3 times for known transient patterns (NCCL timeout, ECC error, segfault, HuggingFace connectivity, …) before declaring a genuine failure.


Recipe YAML Structure

Recipes live in tests/testutils/recipes/ and are parsed by tests/testutils/pythonscripts/recipeparser.py. Each file expands a cartesian products block into individual workload specs:

type: basic
format_version: 1
maintainers: [mcore]
loggers: [stdout]
spec:
  name: "{test_case}_{environment}_{platforms}"
  model: gpt              # maps to tests/functional_tests/test_cases/{model}/
  build: mcore-pyt-{environment}
  nodes: 1
  gpus: 8
  n_repeat: 5
  platforms: dgx_h100
  time_limit: 1800
  script_setup: |
    ...
  script: |-
    bash tests/functional_tests/shell_test_utils/run_ci_test.sh ...
products:
  - test_case: [my_test]
    products:
      - environment: [dev, lts]
        scope: [mr-github]
        platforms: [dgx_h100]

Key runtime placeholders: {assetsdir}, {artifactsdir}, {testcase}, {environment}, {platforms}, {nrepeat}.

Disabling a Test Without Deleting It

To temporarily disable a test case in a recipe YAML, suffix its scope value with -brokendo not delete the entry:

# before (test runs in CI)
scope: [mr-github]

# after (test is skipped; entry preserved for easy re-enable)
scope: [mr-github-broken]

Running Unit Tests Locally

All unit tests initialize a torch.distributed group, so every invocation requires GPU access and must go through torch.distributed.run:

# Full suite
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
  tests/unit_tests

# Single file
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
  tests/unit_tests/models/test_gpt_model.py

# Single test
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
  tests/unit_tests/models/test_gpt_model.py::TestGPTModel::test_constructor

# Filter by name substring
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
  tests/unit_tests -k optimizer

Marker filters

# Exclude flaky tests during development
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
  tests/unit_tests -m "not flaky and not flaky_in_dev"

# Include experimental tests
uv run python -m torch.distributed.run --nproc-per-node 8 -m pytest -q \
  tests/unit_tests --experimental

CI parity

Use tests/unittests/runci_test.sh to reproduce a CI bucket failure exactly. For ad-hoc runs, prefer the direct torch.distributed.run invocations above.

Gotchas

  • pyproject.toml sets addopts = --durations=15 -s -rA — stdout is not

captured (-s), so ranks interleave during multi-rank runs. Override with --capture=fd when debugging a specific rank.

  • tests/unit_tests/conftest.py looks for test data under /opt/data and

attempts a download if missing. Supply it manually or skip data-dependent tests when running outside the canonical container.


Adding a Unit Test

  1. Create tests/unittests/<category>/test<name>.py.
  2. Use fixtures from tests/unit_tests/conftest.py.
  3. Apply markers as needed:

- @pytest.mark.internal — skipped on legacy tag - @pytest.mark.flakyindev — skipped in dev environment (CI default; use this to disable a flaky test without blocking the standard pipeline) - @pytest.mark.flaky — skipped in lts environment - @pytest.mark.experimentallatest tag only

  1. Verify locally (see Running Unit Tests Locally above).
  2. If the test needs a dedicated CI bucket, add an entry to

tests/test_utils/recipes/h100/unit-tests.yaml.


Adding a Functional / Integration Test

  1. Create tests/functionaltests/testcases/<model>/<test_name>/.
  2. Write modelconfig.yaml with MODELARGS, ENVVARS, and TESTTYPE.
  3. Add a YAML recipe under tests/test_utils/recipes/h100/ (and gb200/ if

needed). Required fields: scope, environment, platform, nrepeat, timelimit.

  1. Push the PR, add the label "Run functional tests" to trigger a full run.
  2. After a successful run, download golden values:

``bash python tests/testutils/pythonscripts/downloadgoldenvalues.py \ --source github --pipeline-id <run-id> ``

  1. Commit the downloaded golden values.

Common Pitfalls

Problem Cause Fix
Test passes locally but fails in CI Different environment or data path Check DATAPATH, DATACACHE_PATH, and the environment tag (dev vs lts)
Golden value mismatch after a code change Numerical regression Download new golden values via downloadgoldenvalues.py after a clean run
cicd-integration-tests-gb200 not triggered GB200 jobs require maintainer status Ask a maintainer to trigger, or add the Run functional tests label