Good morning. Documentation typo found on (<https...
# general
c
The line:
We recommend that you configure your CI system to store the pants log (
.pantsd.d/pants.log
) as a build artifact, so that it is available in case you need to troubleshoot CI issues.
Should read:
We recommend that you configure your CI system to store the pants log (
.pants.d/pants.log
) as a build artifact, so that it is available in case you need to troubleshoot CI issues.
i.e. there are too many "d" s in the path
e
c
Oh! alright...well I will do that here in a bit then. Thanks John.
@enough-analyst-54434: Yeah this has been a minute, but is there a naming convention I should use for the branch off of main for the documentation update? and whom should I put on the review? (is there a page documenting the development process)....
e
You should fork the pants repo and create the PR using your fork. At that point the branch name is only in your fork and the convention is up to you. I will note a pro-tip for OSS repos hosted on github / gitlab, etc -> don't trust / look for contribution docs - docs lie: just look at recent PRs! If the project is somewhat sane, the PRs should exhibit what is expected.
As for who to put on the review - git blame is my tool of choice. Recent editors of the file and / or looking at the edit PRs to see who reviewed those. Another trick that works across OSS projects.