Skip to content

Commit

Permalink
Update docs site for version 2.19.1 (#168)
Browse files Browse the repository at this point in the history
  • Loading branch information
WorkerPants committed Mar 4, 2024
1 parent 269e038 commit ac1d705
Show file tree
Hide file tree
Showing 24 changed files with 784 additions and 793 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -418,17 +418,7 @@ It may be helpful to consider the following:
- if you experience `mypy` typing issues using the `softwrap` for documenting subclasses of `Field` and `Target` classes, consider using the `help_text` convenience function
- text inside the angle brackets (e.g. `<value>`) will be ignored when rendered if not wrapped in backticks
- to create a numbered or bullet list, use 2 space indentation (or use the `bullet_list` convenience function)
- to create a codeblock, use 4 space indentation (no need for triple backticks) and add one empty line between the code block and the text
- to create a codeblock, never use indentation. Only ever use triple-backtick blocks.
- make sure to use backticks to highlight config sections, command-line arguments, target names, and inline code examples.

It may be difficult to confirm the accuracy of text formatting in plain Python, so you may want to generate the relevant Markdown files to be able to preview them to confirm your help strings are rendered as expected. They can be converted into Markdown files for visual inspection using a custom build script.

You can run these commands to convert help strings to Markdown files for the `main` and your local feature branches to identify the changed files and then preview only the relevant files to confirm the rendering makes sense.

```text
$ git checkout main
$ pants run build-support/bin/generate_docs.py -- --no-prompt --output main-docs
$ git checkout <your-branch>
$ pants run build-support/bin/generate_docs.py -- --no-prompt --output branch-docs
$ diff -qr main-docs branch-docs
```
It may be difficult to confirm the accuracy of text formatting in plain Python, so you may want to run `pants help` on the relevant target/subsystem to see the resulting string.
Original file line number Diff line number Diff line change
Expand Up @@ -97,33 +97,7 @@ $ git checkout -b 2.9.x
$ git push upstream 2.9.x
```

## Step 2: Update this docs site

Note that this step can currently only be performed by a subset of maintainers due to a paid maximum number of seats. If you do not have a readme.com account, contact someone in the `#maintainers-confidential` channel in Slack to help out.

### `dev0` - set up the new version

Go to the [documentation dashboard](https://dash.readme.com/). In the top left dropdown, where it says the current version, click "Manage versions". Click "Add new version" and use a "v" with the minor release number, e.g. "v2.9". Fork from the prior release. Mark this new version as public by clicking on "Is public?"

### Sync the `docs/` content

See the `docs/NOTES.md` for instructions setting up the necessary Node tooling your first time.
You'll need to 1st login as outlined there via some variant of `npx rdme login --2fa --project pants ...`.
On the relevant release branch, run `npx rdme docs docs/markdown --version v<pants major>.<pants minor>`; e.g: `npx rdme docs docs/markdown --version v2.8`.

### Regenerate the reference docs

Still on the relevant release branch, run `./pants run build-support/bin/generate_docs.py -- --sync --api-key <key>` with your key from [https://dash.readme.com/project/pants/v2.8/api-key](https://dash.readme.com/project/pants/v2.8/api-key).

### `stable` releases - Update the default docsite

The first stable release of a branch should update the "default" version of the docsite. For example: when releasing the stable `2.9.0`, the docsite would be changed to pointing from `v2.8` to pointing to `v2.9` by default.

:::caution Don't have edit access?
Ping someone in the `#maintainers-confidential` channel in Slack to be added. Alternatively, you can "Suggest edits" in the top right corner.
:::

## Step 3: Tag the release to trigger publishing
## Step 2: Tag the release to trigger publishing

Once you have merged the `VERSION` bump — which will be on `main` for `dev` and `a0` releases, and on the release branch for release candidates — tag the release commit to trigger wheel building and publishing.

Expand All @@ -141,7 +115,7 @@ Then, run:

This will tag the release with your PGP key, and push the tag to origin, which will kick off a [`Release` job](https://github.com/pantsbuild/pants/actions/workflows/release.yaml) to build the wheels and publish them to PyPI.

## Step 4: Test the release
## Step 3: Test the release

Run this script as a basic smoke test:

Expand All @@ -151,7 +125,7 @@ Run this script as a basic smoke test:

You should also check [GitHub Releases](https://github.com/pantsbuild/pants/releases) to ensure everything looks good. Find the version you released, then click it and confirm that the "Assets" list includes PEXes for macOS and Linux.

## Step 5: Run release testing on public repositories
## Step 4: Run release testing on public repositories

Manually trigger a run of the [public repositories testing workflow](https://github.com/pantsbuild/pants/actions/workflows/public_repos.yaml), specifying the version just published as the "Pants version".

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,9 @@ It is strongly recommended that these tools be installed from a hermetic lockfil

The only time you need to think about this is if you want to customize the tool requirements that Pants uses. This might be the case if you want to modify the version of a tool or add extra requirements (for example, tool plugins).

:::caution Exporting tools requires a custom lockfile
:::

If you want a tool to be installed from some resolve, instead of from the built-in lockfile, you set `install_from_resolve` and `requirements` on the tool's config section:

```toml title="pants.toml"
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ The `command` field is passed to `bash -c <command>`. The execution sandbox will

The command is limited to operating on the specific set of input files provided as dependencies, and only produces output files for other targets to consume. It is not possible to mutate any file in the workspace.

In case there are resulting files that should be captured and passed to any consuming targets, list them in the `outputs` field. To capture directories, simply add the path to the directory, with a trailing slash (as in the example `"files/"`, above).
In case there are resulting files that should be captured and passed to any consuming targets, list them in the `outputs` field. To capture directories, simply add the path to the directory, with a trailing slash (as in the example `files/`, above).

:::note Idempotency requirement
The shell command may be cancelled or retried any number of times, so it is important that any side effects are idempotent. That is, it should not matter if it is run several times, or only partially.
Expand Down
2 changes: 1 addition & 1 deletion versioned_docs/version-2.19/docs/terraform/_category_.json
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
{
"label": "TERRAFORM",
"label": "Terraform",
"position": 11
}
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ The `--py-resolve-format=symlinked_immutable_virtualenv` option symlinks to an i

### Tool virtualenvs

`pants export` can also create a virtualenv for each of the Python tools you use via Pants, such as `black`, `isort`, `pytest`, `mypy`, `flake8` and so on (you can run `/pants help tools` to get a list of the tools Pants uses). Use the tool name as the resolve name argument to the `--resolve` flag. This allows you to configure your editor to use the same version of the tool as Pants does for workflows like formatting on save.
`pants export` can also create a virtualenv for each of the Python tools you use via Pants, such as `black`, `isort`, `pytest`, `mypy`, `flake8` and so on. This allows you to configure your editor to use the same version of the tool as Pants does for workflows like formatting on save. Follow [the instructions for creating a tool lockfile](../../python/overview/lockfiles#lockfiles-for-tools).

## Generated code

Expand Down
2 changes: 2 additions & 0 deletions versioned_docs/version-2.19/reference/goals/export.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,8 @@ pants export [args]

Export Pants data for use in other tools, such as IDEs.

:::caution Exporting tools requires creating a custom lockfile for them Follow [the instructions for creating tool lockfiles](../../docs/python/overview/lockfiles#lockfiles-for-tools) :::

Backend: <span className="color--primary">`pants.core`</span>

Config section: <span className="color--primary">`[export]`</span>
Expand Down

0 comments on commit ac1d705

Please sign in to comment.