Open
Conversation
I did some formatting changes
RulaHallak
requested review from
amaslenn,
jeffnvidia and
srivatsankrishnan
as code owners
Contributor
Greptile SummaryThis PR performs a broad documentation restructuring across the Key changes:
Confidence Score: 4/5
Important Files Changed
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
📝 WalkthroughWalkthroughWide-ranging documentation edits: added Tutorial and Troubleshooting pages, restructured USER_GUIDE and reporting, refined DEV and index, introduced workloads installation/requirements docs, and applied numerous wording, heading-capitalization, and small content adjustments across many workload and systems docs. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ❌ 2❌ Failed checks (2 inconclusive)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
doc/workloads/ai_dynamo.rst (1)
7-87:⚠️ Potential issue | 🟡 MinorConsider reverting awkward grammar change.
While most heading capitalization improvements are good, Line 54 introduces awkward phrasing: "The total number of the required nodes" should remain "The total number of required nodes" (without the extra "the").
Additionally, Line 75 changes to passive voice ("The job progress monitoring can be done") which is less direct than the original active voice ("One can monitor job progress"). Consider keeping active voice for clarity.
📝 Suggested improvements
-The total number of the required nodes must be: +The total number of required nodes must be:-The job progress monitoring can be done using either of the following options: +Job progress can be monitored using either of the following options:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@doc/workloads/ai_dynamo.rst` around lines 7 - 87, Update the two awkward phrasing changes in the ai_dynamo.rst content: replace "The total number of the required nodes" with "The total number of required nodes" (remove the extra "the") and change the passive sentence "The job progress monitoring can be done using either of the following options:" back to an active form such as "One can monitor job progress using either of the following options:" so the headings and instructions read naturally; locate and edit the exact phrases quoted above in the doc to apply these replacements.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@doc/DEV.rst`:
- Around line 42-46: The fragment around "For example:" in doc/DEV.rst is
incomplete; merge/rewrite the sentences so the example completes the
thought—e.g., change the three lines into a single clear sentence like "Some
prerequisites can be installed; for example, Docker images and git repos with
executable scripts." and then keep the follow-up sentence "All such
'installables' are kept under ``install_path`` system." Locate the text
containing the quoted phrases "For example:" and "All such \"installables\" are
kept under ``install_path`` system." and update them accordingly.
In `@doc/USER_GUIDE.rst`:
- Line 215: Replace the passive sentence "It is possible to override some args
or even fully define a workload inside a scenario file:" with an active-voice
variant that directly addresses the reader or the agent performing the action,
for example starting with "You can override..." or "Override some args or even
fully define a workload inside a scenario file:"; locate the exact sentence (the
string "It is possible to override some args or even fully define a workload
inside a scenario file:") in USER_GUIDE.rst and update it to one of those active
phrasings to improve clarity and readability.
- Line 256: Replace the passive sentence "Once the test scenario is completed,
it is possible to generate reports using the following command:" with an
active-voice construction; e.g., rephrase to "Once you complete the test
scenario, generate reports using the following command:" so the instruction
reads more direct and clear in USER_GUIDE.rst.
---
Outside diff comments:
In `@doc/workloads/ai_dynamo.rst`:
- Around line 7-87: Update the two awkward phrasing changes in the ai_dynamo.rst
content: replace "The total number of the required nodes" with "The total number
of required nodes" (remove the extra "the") and change the passive sentence "The
job progress monitoring can be done using either of the following options:" back
to an active form such as "One can monitor job progress using either of the
following options:" so the headings and instructions read naturally; locate and
edit the exact phrases quoted above in the doc to apply these replacements.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 133e7610-b2c0-407f-98bf-81b3a3b7c919
📒 Files selected for processing (5)
doc/DEV.rstdoc/USER_GUIDE.rstdoc/reporting.rstdoc/workloads/ai_dynamo.rstdoc/workloads_requirements_installation.rst
Did some structural and formatting changes
Contributor
There was a problem hiding this comment.
Actionable comments posted: 13
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@doc/index.rst`:
- Line 10: Replace the placeholder date "April xx, 2026" in the release history
row for "v1.5.0" with the actual release date; locate the table entry containing
the string "v1.5.0" and update the middle column from "April xx, 2026" to the
correct date (e.g., "April 12, 2026") so the update history shows a concrete
release date.
In `@doc/troubleshooting.rst`:
- Around line 29-31: Update the troubleshooting instructions that currently
instruct users to rerun tests via an "sbatch" command so they are scoped by
scheduler/backend: replace the three bullets referencing "sbatch" with
conditional guidance such as "For Slurm runs: inspect debug.log for the sbatch
command and rerun the generated sbatch script; For Kubernetes runs: inspect the
submitted Job/Pod spec and controller logs or use kubectl to view and re-run the
job; For standalone/local runs: inspect the command executed in debug.log and
re-run it locally." Specifically edit the bullets that mention "sbatch" (the
phrases "sbatch" and "sbatch script") in doc/troubleshooting.rst to include
separate, brief steps per backend (Slurm, Kubernetes, standalone).
In `@doc/Tutorial.rst`:
- Line 146: Replace the circular sentence "Test configuration describes a
particular test configuration to be run" with a clearer definition: say that a
Test configuration specifies the settings used to run a test (based on a test
definition) and will be used in a test scenario — e.g., "A Test configuration
specifies the settings used to run a test; it is based on a test definition and
is used within a test scenario." Update the sentence in the Tutorial.rst section
that introduces CONFIGS_DIR/tests/nccl_test.toml and the built-in NcclTest so it
uses this non-circular phrasing.
- Line 170: The phrase "test description" in the sentence "Test Scenario uses
test description from Step 5. Below is the ``CONFIGS_DIR/scenario.toml`` file:"
should be replaced with the project's standard term "test configuration" to keep
documentation consistent; update that sentence in Tutorial.rst (the line
referencing CONFIGS_DIR/scenario.toml / "Test Scenario uses ... from Step 5") so
it reads "Test Scenario uses test configuration from Step 5." (or equivalent
phrasing using "test configuration") throughout the document.
- Line 120: Replace the circular sentence "System configuration describes how
the system configuration works" with a concise explanatory sentence such as
"This section explains how to configure the system and provides an example
configuration file" and ensure the paragraph then points readers to the example
location under conf/common/system/ and the sample CONFIGS_DIR/system.toml file;
update the sentence in the Tutorial.rst content so it clearly states purpose and
references the example paths.
- Line 4: The opening sentence uses the misleading phrase "create CloudAI
framework"; update it to clearly state the tutorial objective by replacing that
phrase with something like "build and run applications using the CloudAI
framework" or "get started with the CloudAI framework" so readers understand
they will learn to use the framework rather than create it—locate the exact text
"create CloudAI framework" and revise it to a clearer description of the
tutorial goal.
- Line 20: The sentence "To create a Docker image, follow the following steps:"
uses redundant wording; update it (in Tutorial.rst) to a concise form such as
"To create a Docker image, follow these steps:" or "To create a Docker image,
follow the steps:" by replacing "follow the following steps" with one of the
suggested alternatives to remove redundancy.
- Line 163: Replace the inconsistent phrase "test schema file" with the
project's standard term "test configuration" in the sentence that starts "You
can find more examples under ``conf/common/test``" (the phrase "test schema
file" is the unique text to change); keep the rest of the sentence intact so
"cmd_args", "extra_cmd_args" and "extra_env_vars" remain unchanged, ensuring the
doc uses "test configuration" consistently with the rest of the document.
In `@doc/USER_GUIDE.rst`:
- Line 448: Replace the sentence-fragment lead-ins "Will result in sbatch file
content like this:" (and the similar instance at the other location) with a
complete-sentence form such as "This will result in the sbatch file containing
the following:" (or "The command will result in the sbatch file containing the
following:") so the subject is explicit and the prose is grammatically complete.
- Line 353: Replace the awkward phrase "sub-items of Slurm-related topics" in
the USER_GUIDE section intro with clearer wording; locate the exact sentence
containing "sub-items of Slurm-related topics" and change it to "subtopics
related to Slurm." Ensure surrounding punctuation and capitalization remain
consistent with the document style.
In `@doc/workloads/ai_dynamo.rst`:
- Line 54: Reword two awkward user-facing sentences to improve grammar and
readability: replace "The total number of the required nodes must be:" with "The
total number of required nodes is:" and similarly simplify the other awkward
sentence (the similar user-facing sentence later in the doc) to "Ensure the
total number of nodes meets the requirement:" so both read clearly and
concisely.
In `@doc/workloads/workloads_requirements_installation.rst`:
- Line 4: The sentence "CloudAI workloads can define multiple installables as
prerequisites. It can be a container image, git repository, HF model, etc." has
a singular/plural mismatch; change the second sentence to use plural agreement
(e.g., "They can be a container image, git repository, HF model, etc." or
rephrase to "These can be...") so "installables" and the following clause agree;
update the sentence in the same paragraph where that text appears.
- Line 10: The phrase "the Docker repository" is ambiguous; update the sentence
"First, make sure you have access to the Docker repository. Proceed as follows:"
to explicitly name the target registry (e.g., "NVIDIA NGC Docker registry" or
"NGC container registry") and, if relevant, add a short parenthetical like
"(NGC)" so subsequent instructions clearly refer to the NGC registry; ensure the
new wording appears exactly where that sentence occurs in
doc/workloads/workloads_requirements_installation.rst.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 88da6b0a-4f00-4a7b-b03e-779f1b12c8b3
📒 Files selected for processing (17)
doc/DEV.rstdoc/Tutorial.rstdoc/USER_GUIDE.rstdoc/index.rstdoc/reporting.rstdoc/systems.rstdoc/troubleshooting.rstdoc/workloads/ai_dynamo.rstdoc/workloads/aiconfigurator.rstdoc/workloads/bash_cmd.rstdoc/workloads/chakra_replay.rstdoc/workloads/ddlb.rstdoc/workloads/deepep.rstdoc/workloads/index.rstdoc/workloads/osu.rstdoc/workloads/vllm.rstdoc/workloads/workloads_requirements_installation.rst
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
♻️ Duplicate comments (3)
doc/workloads/ai_dynamo.rst (1)
75-75:⚠️ Potential issue | 🟡 MinorSimplify awkward monitoring sentence on Line 75.
Current wording is hard to read. Prefer: “You can monitor job progress using either of the following options:”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@doc/workloads/ai_dynamo.rst` at line 75, Replace the awkward sentence that currently begins "The job progress monitoring can be done using either of the following options:" with the clearer wording: "You can monitor job progress using either of the following options:". Locate the sentence in the documentation paragraph describing job progress monitoring (the sentence currently starting "The job progress monitoring...") and update it verbatim to the suggested phrasing, preserving surrounding punctuation and formatting.doc/workloads/workloads_requirements_installation.rst (2)
4-4:⚠️ Potential issue | 🟡 MinorFix plural agreement in installables description.
Line 4 still uses a plural subject with a singular follow-up (“multiple installables” vs “The installable”). Please keep number agreement consistent.
Proposed fix
-CloudAI workloads can define multiple installables as prerequisites. The installable can be a container image, git repository, HF model, etc. +CloudAI workloads can define multiple installables as prerequisites. Installables can be container images, git repositories, Hugging Face models, etc.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@doc/workloads/workloads_requirements_installation.rst` at line 4, The sentence with number disagreement uses "multiple installables" followed by "The installable can be..."; fix by making the noun and verb agree—replace "The installable can be a container image, git repository, HF model, etc." with either "Installables can be a container image, git repository, HF model, etc." or "An installable can be a container image, git repository, HF model, etc." so the plurality matches the earlier phrase; update the phrase in the same paragraph where "multiple installables" appears.
10-10:⚠️ Potential issue | 🟡 MinorClarify which Docker registry is required.
Line 10 says “the Docker repository,” which is ambiguous in this context. Naming NGC explicitly will make the setup steps clearer.
Proposed fix
-First, make sure you have access to the Docker repository. Proceed as follows: +First, make sure you have access to the NVIDIA NGC container registry. Proceed as follows:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@doc/workloads/workloads_requirements_installation.rst` at line 10, Replace the ambiguous phrase "the Docker repository" with an explicit reference to NVIDIA's registry by renaming it to "the NVIDIA NGC (NVIDIA GPU Cloud) Docker registry" (or similar wording) where it appears in this document—specifically the sentence containing "the Docker repository"—and optionally add a brief parenthetical or link to NGC for clarity; ensure the phrasing is consistent throughout the file doc/workloads/workloads_requirements_installation.rst.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@doc/Tutorial.rst`:
- Line 194: Update the sentence containing ``test_name`` so it reads "The
``test_name`` specifies the test definition from one of the Test TOML files.
Node lists and time limits are optional." — insert the missing article "the"
before "test definition" in the existing line referencing ``test_name``.
- Line 79: Edit the sentence that currently begins "Test definition is a
Pydantic model..." to include the article "A" so it reads "A test definition is
a Pydantic model..." and keep the rest of the sentence unchanged; refer to the
documentation sentence describing the TestDefinition class to locate and update
this line.
- Line 92: Update the sentence referencing the parameter "an_arg" so it reads
"has a mixed type of" instead of "has mixed type of" — find the line containing
"an_arg" and replace "has mixed type of ``str | list[str]``" with "has a mixed
type of ``str | list[str]``" to correct the grammar.
- Around line 196-202: Clarify the dependency semantics: state that each
dependency entry is a pair of the depending test id (use the test scenario
name/id) and an optional delay in seconds, and update wording for the three
dependency types (`start_post_comp`, `start_post_init`, `end_post_comp`) to say
when the dependent test starts or must complete and whether the optional `delay`
is applied (e.g., `start_post_comp` — start after the other test completes plus
optional delay; `start_post_init` — start after the other test starts plus
optional delay; `end_post_comp` — must complete after the other test completes
plus optional delay), specify the default when `delay` is omitted (default 0
seconds), and update the example to include explicit `delay` fields and fix the
awkward phrasing ("after a specific delay following the completion" or similar).
In `@doc/USER_GUIDE.rst`:
- Line 494: Update the sentence to include the missing article before "file
system" — change "When compute nodes do not share file system with head node" to
either "When compute nodes do not share a file system with the head node" or
"When compute nodes do not share the file system with the head node"; apply this
edit in the USER_GUIDE.rst paragraph that includes the description of
"--enable-cache-without-check" for "run" and "dry-run".
---
Duplicate comments:
In `@doc/workloads/ai_dynamo.rst`:
- Line 75: Replace the awkward sentence that currently begins "The job progress
monitoring can be done using either of the following options:" with the clearer
wording: "You can monitor job progress using either of the following options:".
Locate the sentence in the documentation paragraph describing job progress
monitoring (the sentence currently starting "The job progress monitoring...")
and update it verbatim to the suggested phrasing, preserving surrounding
punctuation and formatting.
In `@doc/workloads/workloads_requirements_installation.rst`:
- Line 4: The sentence with number disagreement uses "multiple installables"
followed by "The installable can be..."; fix by making the noun and verb
agree—replace "The installable can be a container image, git repository, HF
model, etc." with either "Installables can be a container image, git repository,
HF model, etc." or "An installable can be a container image, git repository, HF
model, etc." so the plurality matches the earlier phrase; update the phrase in
the same paragraph where "multiple installables" appears.
- Line 10: Replace the ambiguous phrase "the Docker repository" with an explicit
reference to NVIDIA's registry by renaming it to "the NVIDIA NGC (NVIDIA GPU
Cloud) Docker registry" (or similar wording) where it appears in this
document—specifically the sentence containing "the Docker repository"—and
optionally add a brief parenthetical or link to NGC for clarity; ensure the
phrasing is consistent throughout the file
doc/workloads/workloads_requirements_installation.rst.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5032018d-8276-4bb9-bdcb-2041fd717f1a
📒 Files selected for processing (4)
doc/Tutorial.rstdoc/USER_GUIDE.rstdoc/workloads/ai_dynamo.rstdoc/workloads/workloads_requirements_installation.rst
| Testing Definition | ||
| ~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| Test definition is a Pydantic model that describes the arguments of a test. Such models should be inherited from the ``TestDefinition`` class: |
Contributor
There was a problem hiding this comment.
Add the article "A" for correct grammar.
The sentence should begin with "A test definition is..." for grammatically correct prose.
📝 Proposed fix
-Test definition is a Pydantic model that describes the arguments of a test. Such models should be inherited from the ``TestDefinition`` class:
+A test definition is a Pydantic model that describes the arguments of a test. Such models should be inherited from the ``TestDefinition`` class:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Test definition is a Pydantic model that describes the arguments of a test. Such models should be inherited from the ``TestDefinition`` class: | |
| A test definition is a Pydantic model that describes the arguments of a test. Such models should be inherited from the ``TestDefinition`` class: |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@doc/Tutorial.rst` at line 79, Edit the sentence that currently begins "Test
definition is a Pydantic model..." to include the article "A" so it reads "A
test definition is a Pydantic model..." and keep the rest of the sentence
unchanged; refer to the documentation sentence describing the TestDefinition
class to locate and update this line.
|
|
||
| Notice that ``cmd_args.docker_image_url`` uses ``nvcr.io/nvidia/pytorch:24.02-py3``, but you can use the Docker image from Step 1. | ||
|
|
||
| ``an_arg`` has mixed type of ``str | list[str]``, so in a TOML config it can be defined as either: |
Contributor
There was a problem hiding this comment.
Add article for correct grammar.
The phrase should read "has a mixed type" rather than "has mixed type".
📝 Proposed fix
-``an_arg`` has mixed type of ``str | list[str]``, so in a TOML config it can be defined as either:
+``an_arg`` has a mixed type of ``str | list[str]``, so in a TOML config it can be defined as either:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ``an_arg`` has mixed type of ``str | list[str]``, so in a TOML config it can be defined as either: | |
| ``an_arg`` has a mixed type of ``str | list[str]``, so in a TOML config it can be defined as either: |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@doc/Tutorial.rst` at line 92, Update the sentence referencing the parameter
"an_arg" so it reads "has a mixed type of" instead of "has mixed type of" — find
the line containing "an_arg" and replace "has mixed type of ``str | list[str]``"
with "has a mixed type of ``str | list[str]``" to correct the grammar.
| Notes on the test scenario: | ||
|
|
||
| #. ``id`` is a mandatory field and must be unique for each test. | ||
| #. The ``test_name`` specifies test definition from one of the Test TOML files. Node lists and time limits are optional. |
Contributor
There was a problem hiding this comment.
Add missing article "the".
The phrase should read "specifies the test definition" for correct grammar.
📝 Proposed fix
-#. The ``test_name`` specifies test definition from one of the Test TOML files. Node lists and time limits are optional.
+#. The ``test_name`` specifies the test definition from one of the Test TOML files. Node lists and time limits are optional.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| #. The ``test_name`` specifies test definition from one of the Test TOML files. Node lists and time limits are optional. | |
| #. The ``test_name`` specifies the test definition from one of the Test TOML files. Node lists and time limits are optional. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@doc/Tutorial.rst` at line 194, Update the sentence containing ``test_name``
so it reads "The ``test_name`` specifies the test definition from one of the
Test TOML files. Node lists and time limits are optional." — insert the missing
article "the" before "test definition" in the existing line referencing
``test_name``.
Comment on lines
+196
to
+202
| #. There are three types of dependencies: ``start_post_comp``, ``start_post_init`` and ``end_post_comp``. | ||
|
|
||
| - ``start_post_comp`` means that the current test should be started after a specific delay of the completion of the depending test. | ||
| - ``start_post_init`` means that the current test should start after the start of the depending test. | ||
| - ``end_post_comp`` means that the current test should be completed after the completion of the depending test. | ||
|
|
||
| All dependencies are described as a pair of the depending test name and a delay. The name should be taken from the test name as set in the test scenario. The delay is described in seconds. |
Contributor
There was a problem hiding this comment.
Clarify dependency delay semantics and fix inconsistent explanation.
The explanation of dependencies contains inconsistencies:
- Line 202 states "All dependencies are described as a pair of the depending test name and a delay," but the example at lines 187-189 shows no
delayfield—onlytypeandid. - Line 198 mentions "after a specific delay of the completion" (awkward phrasing), while line 199's explanation of
start_post_initdoesn't mention delay at all.
This creates confusion about whether the delay field is required, optional, or only applies to certain dependency types.
📋 Suggested clarifications
Please clarify:
- Is
delayan optional field for all dependency types, or only for certain types? - What is the default behavior if
delayis omitted? - Should the example include a
delayfield for completeness?
Also fix the awkward grammar at line 198:
- - ``start_post_comp`` means that the current test should be started after a specific delay of the completion of the depending test.
+ - ``start_post_comp`` means that the current test starts after the depending test completes, with an optional delay.And revise line 202 to accurately reflect whether delay is always required:
- All dependencies are described as a pair of the depending test name and a delay. The name should be taken from the test name as set in the test scenario. The delay is described in seconds.
+ All dependencies reference the depending test's ``id`` from the test scenario. An optional ``delay`` (in seconds) may be specified for certain dependency types.(Adjust the wording based on the actual intended behavior.)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@doc/Tutorial.rst` around lines 196 - 202, Clarify the dependency semantics:
state that each dependency entry is a pair of the depending test id (use the
test scenario name/id) and an optional delay in seconds, and update wording for
the three dependency types (`start_post_comp`, `start_post_init`,
`end_post_comp`) to say when the dependent test starts or must complete and
whether the optional `delay` is applied (e.g., `start_post_comp` — start after
the other test completes plus optional delay; `start_post_init` — start after
the other test starts plus optional delay; `end_post_comp` — must complete after
the other test completes plus optional delay), specify the default when `delay`
is omitted (default 0 seconds), and update the example to include explicit
`delay` fields and fix the awkward phrasing ("after a specific delay following
the completion" or similar).
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| When compute nodes don't share file system with head node, ``--enable-cache-without-check`` for ``run`` and ``dry-run`` skips the real check for cache existence, but still builds all paths correctly. The flow is like this: | ||
| When compute nodes do not share file system with head node, ``--enable-cache-without-check`` for ``run`` and ``dry-run`` skips the real check for cache existence, but still builds all paths correctly. The flow is like this: |
Contributor
There was a problem hiding this comment.
Add missing article before "file system".
The phrase should include an article: either "do not share a file system" or "do not share the file system".
📝 Proposed fix
-When compute nodes do not share file system with head node, ``--enable-cache-without-check`` for ``run`` and ``dry-run`` skips the real check for cache existence, but still builds all paths correctly. The flow is like this:
+When compute nodes do not share a file system with the head node, ``--enable-cache-without-check`` for ``run`` and ``dry-run`` skips the real check for cache existence, but still builds all paths correctly. The flow is like this:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| When compute nodes do not share file system with head node, ``--enable-cache-without-check`` for ``run`` and ``dry-run`` skips the real check for cache existence, but still builds all paths correctly. The flow is like this: | |
| When compute nodes do not share a file system with the head node, ``--enable-cache-without-check`` for ``run`` and ``dry-run`` skips the real check for cache existence, but still builds all paths correctly. The flow is like this: |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@doc/USER_GUIDE.rst` at line 494, Update the sentence to include the missing
article before "file system" — change "When compute nodes do not share file
system with head node" to either "When compute nodes do not share a file system
with the head node" or "When compute nodes do not share the file system with the
head node"; apply this edit in the USER_GUIDE.rst paragraph that includes the
description of "--enable-cache-without-check" for "run" and "dry-run".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
I did some formatting changes.
Test Plan
Additional Notes
N/A