Document exit code handling for composite actions #31974
Conversation
github-actions
bot
added
the
triage
Automatically generated comment ℹ️This comment is automatically generated and will be overwritten every time changes are committed to this branch. The table contains an overview of files in the Content directory changesYou may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.
fpt: Free, Pro, Team |
|
@jsoref Hello! 👋 Let us know once this PR is ready for review |
nguyenalex836
added
content
|
I'm still fighting the linter (quite likely not this week) |
|
@nguyenalex836: this is ready for review -- I spent a nontrivial amount of time fighting liquid -- I don't understand it and really don't like the output it reports -- it'd be much better if it included a link to a page explaining when & how to use |
nguyenalex836
added
waiting for review
|
@jsoref Thanks for letting me know!
Understood - will flag this internally when I triage for review shortly 👍 |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
There was a problem hiding this comment.
Hey @jsoref, thanks for opening this pull request to add a composite action example to this article. 💛
I left a couple of asks to edit some things before we can approve this PR and add it to the docs. Let me know if you have any questions!
| @@ -17,10 +17,10 @@ type: how_to | |||
|
|
|||
| {% data variables.product.prodname_dotcom %} uses the exit code to set the action's check run status, which can be `success` or `failure`. | |||
|
|
|||
| Exit status | Check run status | Description | |||
| ------------|------------------|------------ | |||
| Exit status | Step conclusion | Description | |||
There was a problem hiding this comment.
| Exit status | Step conclusion | Description | |
| Exit status | Check run status | Description |
Just updating this to match the language in the prior sentence and other language used throughout GitHub.
There was a problem hiding this comment.
This is wrong.
GitHub Actions Runtime maps GitHub Jobs to Check Runs. Beneath jobs are a number of other layers.
We aren't directly in a check run (GitHub Job), we're in an action inside another thing which might or might not surface that outcome. It's a fundamental problem with this documentation, it's absolutely ignorant of the fact that composite actions can nest (and have been able to for a very long time). I believe you can in fact have 10 levels of nesting in composite actions.
In some ways, check-spelling is boring, it doesn't generally nest composite actions by more than two layers, although it definitely envisions people calling it in their own composite action (and thus adding at least one more layer). Most of the actions that check-spelling calls don't have many steps in them (if they're composite actions), but that's an implementation detail of the individual actions and not a constraint by the actions subsystem. The actions we're starting to use internally will probably have multiple steps in second layer nested actions. And it's quite likely that they'll include continue-on-error.
A very incomplete diagram of check-spelling
graph TB
Workflow{ Spelling Workflow } -- Job --> JobCheckSpelling(( check-spelling ))
Workflow -- Job --> JobComment(( comment))
JobCheckSpelling -- job step1 --> CheckSpellingAction[ uses: check-spelling/check-spelling ]
CheckSpellingAction -- action step 1 --> CheckSpellingActionStep1( act-broken - run bash )
CheckSpellingActionStep1 -- action step 2 --> CheckSpellingActionStep2( act-windows-shim )
CheckSpellingActionStep2 -- action step 3 --> CheckSpellingActionStep3( parse-alternate-engine )
CheckSpellingActionStep3 -- action step 4 --> CheckSpellingActionStep4[ alternate-engine uses: actions/checkout ]
CheckSpellingActionStep4 -- potential steps in nested action --> ActionsCheckoutStep1(( implementation details... ))
ActionsCheckoutStep1 --> CheckSpellingActionStep5
CheckSpellingActionStep4 -- action step 5 --> CheckSpellingActionStep5( shim-path )
CheckSpellingActionStep5 -- action step 6 --> CheckSpellingActionStep6( check-actions )
CheckSpellingActionStep6 -- action step 7 --> CheckSpellingActionStep7[ checkout-replacement uses: check-spelling/actions-checkout ]
CheckSpellingActionStep7 -- potential steps in nested action --> CheckSpellingActionsCheckoutStep11(( implementation details... ))
CheckSpellingActionsCheckoutStep11 --> CheckSpellingActionStep8
CheckSpellingActionStep7 -- action step 8 --> CheckSpellingActionStep8[ checkout uses: check-actions/checkout ]
CheckSpellingActionStep8 -- action step 9 --> CheckSpellingActionStep9( report if checkout failed )
CheckSpellingActionStep9 -- action step 10 --> CheckSpellingActionStep10[ checkout-merge uses: check-spelling/checkout-merge ]
CheckSpellingActionStep10 -- action step 11 --> CheckSpellingActionStep11( raise-merge-failure )
CheckSpellingActionStep11 -- action step 12 --> CheckSpellingActionStep12( save sha )
CheckSpellingActionStep12 -- action step 13 --> CheckSpellingActionStep13( prepare )
CheckSpellingActionStep13 -- action step 14 --> CheckSpellingActionStep14[ retrieve-comment-matrix-replacement uses: check-spelling/actions-download-artifact ]
CheckSpellingActionStep14 -- action step 15 --> CheckSpellingActionStep15[ retrieve-comment-replacement uses: check-spelling/actions-download-artifact ]
CheckSpellingActionStep14 -- potential steps in nested action --> CheckSpellingActionsDownloadArtifact(( implementation details... ))
CheckSpellingActionStep15 -- action step 16 --> CheckSpellingActionStep16( retrieve-comment )
CheckSpellingActionStep15 -- potential steps in nested action --> CheckSpellingActionsDownloadArtifact(( implementation details... ))
CheckSpellingActionsDownloadArtifact --> CheckSpellingActionStep15
CheckSpellingActionStep16 -- action step 17 --> CheckSpellingActionStep17( hash-dictionaries )
CheckSpellingActionStep17 -- action step 18 --> CheckSpellingActionStep18[ retrieve-dictionaries uses: actions/cache/restore ]
CheckSpellingActionStep18 -- action step 19 --> CheckSpellingActionStep19( perl-config )
CheckSpellingActionStep19 -- action step 20 --> CheckSpellingActionStep20[ retrieve-perl-libraries-arch uses: actions/cache/restore ]
CheckSpellingActionStep20 -- potential steps in nested action --> ActionsCacheRestore(( implementation details... ))
ActionsCacheRestore --> CheckSpellingActionStep21[ retrieve-perl-libraries-lib uses: actions/cache/restore ]
CheckSpellingActionStep20 -- action step 21 --> CheckSpellingActionStep21
CheckSpellingActionStep21 -- potential steps in nested action --> ActionsCacheRestore
CheckSpellingActionStep21 --> CheckSpellingActionStep22( install perl modules )
CheckSpellingActionStep22 -- action step 23 --> CheckSpellingActionStep23( spelling)
CheckSpellingActionStep23 -- action step 24 --> CheckSpellingActionStep24[ save-dictionaries uses: actions/cache/save ]
CheckSpellingActionStep24 -- action step 25 --> CheckSpellingActionStep25[ save-perl-libraries-lib uses: actions/cache/save ]
CheckSpellingActionStep24 -- potential steps in nested action --> ActionsCacheSave(( implementation details... ))
CheckSpellingActionStep25 -- potential steps in nested action --> ActionsCacheSave
ActionsCacheSave --> CheckSpellingActionStep26
CheckSpellingActionStep25 -- action step 26 --> CheckSpellingActionStep26[ store comment replacement uses: check-spelling/actions-upload-artifact ]
CheckSpellingActionStep26 -- potential steps in nested action --> CheckSpellingUploadArtifact(( implementation details... ))
JobComment --> CheckSpellingAction
Workflow -- Job --> JobUpdate(( update))
JobUpdate --> CheckSpellingAction
CheckSpellingActionStep10 -- checkout-merge step 1 --> CheckoutMergeStep1( merge )
CheckoutMergeStep1 --> CheckoutMergeStep2( there could be more steps here... )
CheckoutMergeStep2 --> CheckSpellingActionStep11
Key{ Key } --> KeyWorkflow{ Workflow }
Key --> Job(( Job ))
Key --> RunStep( run step )
Key --> UsesAction[ uses action ]
UsesAction --> ImplementationDetails(( implementation details ))
KeyWorkflow --> Job
Job --> RunStep
Job --> UsesAction
Job -- up to 3 levels of nesting --> Job
Job -- Set check run status --> CheckRunStatus{ ... }
UsesAction --> RunStep
UsesAction -- up to 9 levels of nesting --> UsesAction
| `0` | `success` | The action completed successfully and other tasks that depend on it can begin. | ||
| Nonzero value (any integer but 0)| `failure` | Any other exit code indicates the action failed. When an action fails, all concurrent actions are canceled and future actions are skipped. The check run and check suite both get a `failure` status. | ||
| Nonzero value (any integer but 0)| `failure` | Any other exit code indicates the action failed. When an action fails unless the step has `continue-on-error: true` the job will be set to `failed` and future steps in the job will be skipped unless they use `if:` with either `always()` or `failed()`. Concurrent jobs will be canceled unless `jobs.<job_id>.strategy.fail-fast` is `false`. |
There was a problem hiding this comment.
| Nonzero value (any integer but 0)| `failure` | Any other exit code indicates the action failed. When an action fails unless the step has `continue-on-error: true` the job will be set to `failed` and future steps in the job will be skipped unless they use `if:` with either `always()` or `failed()`. Concurrent jobs will be canceled unless `jobs.<job_id>.strategy.fail-fast` is `false`. | |
| Nonzero value (any integer but 0)| `failure` | Any other exit code indicates the action failed. When an action fails, all concurrent actions are canceled and future actions are skipped. The check run and check suite both get a `failure` status. |
Since this article is aimed at people who are creating actions, I think the original text here makes more sense. If someone is writing a workflow and they don't want dependent jobs to be skipped because of a failed action, they can find that information in the Workflow syntax article.
There was a problem hiding this comment.
Nope, you might think that, but that's because the action syntax documentation is out of date. See #31356 (comment).
I just spent a nontrivial amount of effort over the last two days w/ a coworker on a private action that uses continue-on-error: true. Yes, it isn't mentioned in https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions but I can assure you that it does work and we relied on it heavily.
check-spelling has been using it publicly for a while too:
https://github.com/check-spelling/check-spelling/blob/e0d8a1df4f07a2afade0882ac903ebfaba4f0bc8/action.yml#L398
The article is aimed at people like me, and I'm trying to fix it based on my experience as an action author.
I don't use continue-on-error in workflows, but I do use it in my actions.
Beyond that, the current text is totally wrong.
The only things concurrent to an action are Jobs, not actions. Within a job you can have actions or run statements, and a run statement in another job will be killed just as much as another action in another job would be killed -- but details about which is killed would be a layering violation -- at most the death of an action leads to a cascade -- its parent action dies until eventually its ancestor action kills its job, and then the death of the job results in the death of the job's siblings, which in turn would result in the death of job steps which may include other actions or run-shell steps. -- But it isn't that the death of the current action triggers any of those things directly, they're at most casualties of other things.
| @@ -48,3 +48,187 @@ fi | |||
| ``` | |||
|
|
|||
| For more information, see "[AUTOTITLE](/actions/creating-actions/creating-a-docker-container-action)." | |||
|
|
|||
| ## Handling exit codes in composite actions | |||
There was a problem hiding this comment.
Would you be able to shorten this whole section to a relevant example that explains how a non-zero exit in the middle of a composite action will cause the remaining composite action to behave? So that it is structured more similarly to the previous two sections about Docker and JavaScript actions?
The audience for this article is people who are creating actions. Because of that, any content that is directed towards people who are writing workflows should be removed from this article. If you think the documentation in the Using workflows section of the docs is missing any of this information, you can definitely open an issue to propose adding it there. 👍
There was a problem hiding this comment.
I don't have the energy to do that at this time. Between dealing w/ a dozen other problems (including runners repeatably dying with my workflows), this was as good as I could manage while still providing something where someone could actually see an outcome.
| @@ -17,10 +17,10 @@ type: how_to | |||
|
|
|||
| {% data variables.product.prodname_dotcom %} uses the exit code to set the action's check run status, which can be `success` or `failure`. | |||
|
|
|||
| Exit status | Check run status | Description | |||
| ------------|------------------|------------ | |||
| Exit status | Step conclusion | Description | |||
There was a problem hiding this comment.
This is wrong.
GitHub Actions Runtime maps GitHub Jobs to Check Runs. Beneath jobs are a number of other layers.
We aren't directly in a check run (GitHub Job), we're in an action inside another thing which might or might not surface that outcome. It's a fundamental problem with this documentation, it's absolutely ignorant of the fact that composite actions can nest (and have been able to for a very long time). I believe you can in fact have 10 levels of nesting in composite actions.
In some ways, check-spelling is boring, it doesn't generally nest composite actions by more than two layers, although it definitely envisions people calling it in their own composite action (and thus adding at least one more layer). Most of the actions that check-spelling calls don't have many steps in them (if they're composite actions), but that's an implementation detail of the individual actions and not a constraint by the actions subsystem. The actions we're starting to use internally will probably have multiple steps in second layer nested actions. And it's quite likely that they'll include continue-on-error.
A very incomplete diagram of check-spelling
graph TB
Workflow{ Spelling Workflow } -- Job --> JobCheckSpelling(( check-spelling ))
Workflow -- Job --> JobComment(( comment))
JobCheckSpelling -- job step1 --> CheckSpellingAction[ uses: check-spelling/check-spelling ]
CheckSpellingAction -- action step 1 --> CheckSpellingActionStep1( act-broken - run bash )
CheckSpellingActionStep1 -- action step 2 --> CheckSpellingActionStep2( act-windows-shim )
CheckSpellingActionStep2 -- action step 3 --> CheckSpellingActionStep3( parse-alternate-engine )
CheckSpellingActionStep3 -- action step 4 --> CheckSpellingActionStep4[ alternate-engine uses: actions/checkout ]
CheckSpellingActionStep4 -- potential steps in nested action --> ActionsCheckoutStep1(( implementation details... ))
ActionsCheckoutStep1 --> CheckSpellingActionStep5
CheckSpellingActionStep4 -- action step 5 --> CheckSpellingActionStep5( shim-path )
CheckSpellingActionStep5 -- action step 6 --> CheckSpellingActionStep6( check-actions )
CheckSpellingActionStep6 -- action step 7 --> CheckSpellingActionStep7[ checkout-replacement uses: check-spelling/actions-checkout ]
CheckSpellingActionStep7 -- potential steps in nested action --> CheckSpellingActionsCheckoutStep11(( implementation details... ))
CheckSpellingActionsCheckoutStep11 --> CheckSpellingActionStep8
CheckSpellingActionStep7 -- action step 8 --> CheckSpellingActionStep8[ checkout uses: check-actions/checkout ]
CheckSpellingActionStep8 -- action step 9 --> CheckSpellingActionStep9( report if checkout failed )
CheckSpellingActionStep9 -- action step 10 --> CheckSpellingActionStep10[ checkout-merge uses: check-spelling/checkout-merge ]
CheckSpellingActionStep10 -- action step 11 --> CheckSpellingActionStep11( raise-merge-failure )
CheckSpellingActionStep11 -- action step 12 --> CheckSpellingActionStep12( save sha )
CheckSpellingActionStep12 -- action step 13 --> CheckSpellingActionStep13( prepare )
CheckSpellingActionStep13 -- action step 14 --> CheckSpellingActionStep14[ retrieve-comment-matrix-replacement uses: check-spelling/actions-download-artifact ]
CheckSpellingActionStep14 -- action step 15 --> CheckSpellingActionStep15[ retrieve-comment-replacement uses: check-spelling/actions-download-artifact ]
CheckSpellingActionStep14 -- potential steps in nested action --> CheckSpellingActionsDownloadArtifact(( implementation details... ))
CheckSpellingActionStep15 -- action step 16 --> CheckSpellingActionStep16( retrieve-comment )
CheckSpellingActionStep15 -- potential steps in nested action --> CheckSpellingActionsDownloadArtifact(( implementation details... ))
CheckSpellingActionsDownloadArtifact --> CheckSpellingActionStep15
CheckSpellingActionStep16 -- action step 17 --> CheckSpellingActionStep17( hash-dictionaries )
CheckSpellingActionStep17 -- action step 18 --> CheckSpellingActionStep18[ retrieve-dictionaries uses: actions/cache/restore ]
CheckSpellingActionStep18 -- action step 19 --> CheckSpellingActionStep19( perl-config )
CheckSpellingActionStep19 -- action step 20 --> CheckSpellingActionStep20[ retrieve-perl-libraries-arch uses: actions/cache/restore ]
CheckSpellingActionStep20 -- potential steps in nested action --> ActionsCacheRestore(( implementation details... ))
ActionsCacheRestore --> CheckSpellingActionStep21[ retrieve-perl-libraries-lib uses: actions/cache/restore ]
CheckSpellingActionStep20 -- action step 21 --> CheckSpellingActionStep21
CheckSpellingActionStep21 -- potential steps in nested action --> ActionsCacheRestore
CheckSpellingActionStep21 --> CheckSpellingActionStep22( install perl modules )
CheckSpellingActionStep22 -- action step 23 --> CheckSpellingActionStep23( spelling)
CheckSpellingActionStep23 -- action step 24 --> CheckSpellingActionStep24[ save-dictionaries uses: actions/cache/save ]
CheckSpellingActionStep24 -- action step 25 --> CheckSpellingActionStep25[ save-perl-libraries-lib uses: actions/cache/save ]
CheckSpellingActionStep24 -- potential steps in nested action --> ActionsCacheSave(( implementation details... ))
CheckSpellingActionStep25 -- potential steps in nested action --> ActionsCacheSave
ActionsCacheSave --> CheckSpellingActionStep26
CheckSpellingActionStep25 -- action step 26 --> CheckSpellingActionStep26[ store comment replacement uses: check-spelling/actions-upload-artifact ]
CheckSpellingActionStep26 -- potential steps in nested action --> CheckSpellingUploadArtifact(( implementation details... ))
JobComment --> CheckSpellingAction
Workflow -- Job --> JobUpdate(( update))
JobUpdate --> CheckSpellingAction
CheckSpellingActionStep10 -- checkout-merge step 1 --> CheckoutMergeStep1( merge )
CheckoutMergeStep1 --> CheckoutMergeStep2( there could be more steps here... )
CheckoutMergeStep2 --> CheckSpellingActionStep11
Key{ Key } --> KeyWorkflow{ Workflow }
Key --> Job(( Job ))
Key --> RunStep( run step )
Key --> UsesAction[ uses action ]
UsesAction --> ImplementationDetails(( implementation details ))
KeyWorkflow --> Job
Job --> RunStep
Job --> UsesAction
Job -- up to 3 levels of nesting --> Job
Job -- Set check run status --> CheckRunStatus{ ... }
UsesAction --> RunStep
UsesAction -- up to 9 levels of nesting --> UsesAction
| `0` | `success` | The action completed successfully and other tasks that depend on it can begin. | ||
| Nonzero value (any integer but 0)| `failure` | Any other exit code indicates the action failed. When an action fails, all concurrent actions are canceled and future actions are skipped. The check run and check suite both get a `failure` status. | ||
| Nonzero value (any integer but 0)| `failure` | Any other exit code indicates the action failed. When an action fails unless the step has `continue-on-error: true` the job will be set to `failed` and future steps in the job will be skipped unless they use `if:` with either `always()` or `failed()`. Concurrent jobs will be canceled unless `jobs.<job_id>.strategy.fail-fast` is `false`. |
There was a problem hiding this comment.
Nope, you might think that, but that's because the action syntax documentation is out of date. See #31356 (comment).
I just spent a nontrivial amount of effort over the last two days w/ a coworker on a private action that uses continue-on-error: true. Yes, it isn't mentioned in https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions but I can assure you that it does work and we relied on it heavily.
check-spelling has been using it publicly for a while too:
https://github.com/check-spelling/check-spelling/blob/e0d8a1df4f07a2afade0882ac903ebfaba4f0bc8/action.yml#L398
The article is aimed at people like me, and I'm trying to fix it based on my experience as an action author.
I don't use continue-on-error in workflows, but I do use it in my actions.
Beyond that, the current text is totally wrong.
The only things concurrent to an action are Jobs, not actions. Within a job you can have actions or run statements, and a run statement in another job will be killed just as much as another action in another job would be killed -- but details about which is killed would be a layering violation -- at most the death of an action leads to a cascade -- its parent action dies until eventually its ancestor action kills its job, and then the death of the job results in the death of the job's siblings, which in turn would result in the death of job steps which may include other actions or run-shell steps. -- But it isn't that the death of the current action triggers any of those things directly, they're at most casualties of other things.
| @@ -48,3 +48,187 @@ fi | |||
| ``` | |||
|
|
|||
| For more information, see "[AUTOTITLE](/actions/creating-actions/creating-a-docker-container-action)." | |||
|
|
|||
| ## Handling exit codes in composite actions | |||
There was a problem hiding this comment.
I don't have the energy to do that at this time. Between dealing w/ a dozen other problems (including runners repeatably dying with my workflows), this was as good as I could manage while still providing something where someone could actually see an outcome.
|
@jsoref Hello 👋 Given the direction and tone of this current discussion regarding the feedback we provided, I'm going to put this PR on hold. It would be beneficial for us all to take a few days and clear our heads with respect to this work. After a few days, please feel free to ping us in this PR and we can continue working together through these updates 💛 |
nguyenalex836
removed
the
waiting for review
|
@jsoref Hi 👋 Regarding the last few messages on this PR, we wanted to clarify @SiaraMist was only reiterating feedback she had received from a senior engineer while tirelessly seeking assistance on how to best support you in this work. If you would like to discuss this feedback, and continue working on this PR, we welcome respectful discourse. We appreciate all of the work you've done for the community in the past, and hope that we can continue working together in the thoughtful and courteous manner our partnership deserves. Please let us know if you would like to continue working on this PR. |
nguyenalex836
added
the
more-information-needed
|
I don't feel I was treated respectfully. My PR wasn't reviewed in good faith. I do not make changes gratuitously. I'll wait for an apology from Siara before continuing. She did not advocate on behalf of the changes to that engineer. |
|
Notably she did not "[Demonstrate] empathy" -- by asking why I needed to make the change to the category just insisted that it be reverted. |
|
@jsoref I'm sorry to hear that. As our goal is to grow an open source community of engagement and respect, we review all contributions in good faith. However, the responses you've submitted recently on this PR are not aligned with this goal. Respect, especially of differing opinions, is taken seriously within our community. For this reason, we will be closing this PR. If in the future, similar disrespectful behavior is demonstrated, you will be temporarily banned from this community. If after a temporary ban you continue to exhibit disrespectful behavior, you will be permanently banned. As previously mentioned, we are appreciative of the contributions you've provided to GitHub Docs. We hope this is an opportunity to grow from this experience, and strengthen our partnership. |
|
For full disclosure, I'm one of @jsoref's friends, I'm primarily a rubber-duck that quacks in his pursuit of ridding the world's software of spelling mistakes. As such he often asks me for my impression or understanding of the GitHub documentation before filing issues or pull requests. I'd like to suggest that bouncing all the conversation through an intermediary isn't very helpful. Playing a game of telephone is well-known to introduce misunderstandings and increase the confusion. This isn't a fair position to put either Siara nor Josh in, and I'll wager the unknown senior engineer behind the curtain wasn't enjoying it much either. If you go through @jsoref's contributions history you'll see dozens of examples of friendly and respectful attempts to improve the documentation and ecosystem: https://github.com/issues?q=is%3Aissue+author%3Ajsoref+archived%3Afalse+org%3Agithub Many of these are met with silence, or auto-close-bots, and sometimes misunderstandings from people who are relying on the documentation rather than experimental results or code inspection. It's easy to get the impression that the docs teams are stretched well beyond their capacities. It's also easy to get the impression that a significant amount of effort is spent trying to synchronize issues, pull requests, and contents, between a public facade and private sources of truth. Are the GitHub teams getting enough value from the separation to justify the costs of maintaining it? I suggest considering embracing the open-source way and engaging directly with the community, at face value. Thanks |
|
@setharnold We appreciate your perspective and transparency. We are reviewing the feedback you've provided above, and will discuss these points internally. Thank you for your desire to improve our OS community 💛 |
|
@nguyenalex836 thanks :) <3 |
Why:
Closes: #31356
What's being changed (if available, include any code snippets, screenshots, or gifs):
https://docs-31974-b67b7f.preview.ghdocs.com/en/actions/creating-actions/setting-exit-codes-for-actions#about-exit-codes
https://docs-31974-b67b7f.preview.ghdocs.com/en/actions/creating-actions/setting-exit-codes-for-actions#handling-exit-codes-in-composite-actions
Check off the following:
I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).
datadirectory.For content changes, I have completed the self-review checklist.