|
| 1 | +# RELEASE-Github.md: Automated Release Workflow |
| 2 | + |
| 3 | +This document details the operation of the NLTK GitHub Actions release workflow, defined in `.github/workflows/release.yml`. This workflow automates the creation of GitHub releases and supports optional PyPI integration for official distribution. |
| 4 | + |
| 5 | +### Workflow Trigger |
| 6 | + |
| 7 | +The workflow is **event-driven**. It is automatically initiated upon pushing a git tag that follows the `v` prefix naming convention to the repository. |
| 8 | + |
| 9 | +* **Trigger Action:** `git push origin v3.10.x-rc` |
| 10 | +* **Requirement:** The workflow file must be present on the target branch. **Crucially, the release tag must point to a commit located within `origin/develop` to ensure the release is built from the authorized development head.** |
| 11 | + |
| 12 | +### Prerequisites & Permissions |
| 13 | + |
| 14 | +Successful execution of this workflow requires specific repository configurations: |
| 15 | + |
| 16 | +* **Write Permissions:** The workflow interacts with the GitHub API to draft releases and create tags; therefore, the triggering actor must have **write** access to the repository. |
| 17 | +* **Fork Execution:** If executing within a fork, ensure the repository settings under **Actions > General > Workflow permissions** are set to "Read and write permissions" to allow the workflow to create release objects. |
| 18 | +* **Secrets:** Ensure all necessary environment secrets (e.g., `PYPI_API_TOKEN` for package publishing) are correctly configured in the repository's secret store. |
| 19 | + |
| 20 | +### Release Strategy: GitHub vs. PyPI |
| 21 | + |
| 22 | +The workflow maintains a clear separation between testing and production release artifacts: |
| 23 | + |
| 24 | +| Stage | Platform | Purpose | |
| 25 | +| --- | --- | --- | |
| 26 | +| **Release Candidate** | GitHub Releases | Early community feedback and environment validation. | |
| 27 | +| **Official Release** | PyPI | Production distribution via `pip` and package repository indexing. | |
| 28 | + |
| 29 | +> **Integration:** While the workflow primarily stages artifacts on GitHub, it is capable of handling **PyPI integration**. If configured, the workflow will automatically publish the build artifacts to PyPI upon successful validation of the release tag. |
| 30 | +
|
| 31 | +### Execution & Verification |
| 32 | + |
| 33 | +1. **Initiate Release:** Trigger the workflow by pushing the appropriate tag to the remote: |
| 34 | +```bash |
| 35 | +git tag v3.10.x-rc |
| 36 | +git push origin v3.10.x-rc |
| 37 | + |
| 38 | +2. **CI Validation:** As implemented in **[#3506](https://github.com/nltk/nltk/pull/3506)**, the workflow performs an automated check to verify that Continuous Integration (CI) has successfully passed on the specific commit to which the release tag points. |
| 39 | +3. **Monitor Logs:** Follow the execution progress in the repository’s **Actions** tab. |
| 40 | +4. **Audit:** If the workflow fails to push to PyPI or draft a release, inspect the logs for: |
| 41 | + * **CI Failures:** Verify the commit status matches the requirements set forth in PR #3506. |
| 42 | + * **Branch Validation:** Ensure the tagged commit is reachable via `origin/develop`. |
| 43 | + * **Authentication errors:** Verify that the `PYPI_API_TOKEN` is active and has the correct scope. |
| 44 | + * **Permission errors:** Confirm that the `GITHUB_TOKEN` has been granted the necessary write access. |
| 45 | + * **Version conflicts:** Ensure the tag is not already associated with an existing release. |
0 commit comments