Repository navigation
feat: modernize Python tooling (pyproject.toml + uv + semantic-release) #466
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
09f0815
e385991
160e476
2447303
6ea65ab
c9f5014
5d93f02
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,117 @@ | ||
| name: Semantic Release | ||
|
|
||
| on: | ||
| push: | ||
| branches: [master] | ||
|
|
||
| jobs: | ||
| # The same aggregate a pull request has to pass, so the release runs exactly | ||
| # the checks that were required to merge -- and picks up any package added to | ||
| # ci.yml later without needing a change here. | ||
| run_ci: | ||
| uses: ./.github/workflows/ci.yml | ||
|
|
||
| release: | ||
| # Every package this workflow publishes has to build before we tag | ||
| # anything. The GitHub release and the PyPI uploads cannot be taken back, | ||
| # so a package that only fails to build in its publish job would leave the | ||
| # release half-finished. | ||
| needs: [run_ci] | ||
| runs-on: ubuntu-latest | ||
| if: github.ref_name == 'master' | ||
| concurrency: | ||
| group: ${{ github.workflow }}-release-${{ github.ref_name }} | ||
| cancel-in-progress: false | ||
|
|
||
| permissions: | ||
| contents: write | ||
|
|
||
| steps: | ||
| # Note: We checkout the repository at the branch that triggered the workflow. | ||
| # Python Semantic Release will automatically convert shallow clones to full clones | ||
| # if needed to ensure proper history evaluation. However, we forcefully reset the | ||
| # branch to the workflow sha because it is possible that the branch was updated | ||
| # while the workflow was running, which prevents accidentally releasing un-evaluated | ||
| # changes. | ||
| - name: Setup | Checkout Repository on Release Branch | ||
| uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 | ||
| with: | ||
| ref: ${{ github.ref_name }} | ||
|
|
||
| - name: Setup | Force release branch to be at workflow sha | ||
| run: | | ||
| git reset --hard ${{ github.sha }} | ||
|
|
||
| - name: Action | Semantic Version Release | ||
| id: release | ||
| # Adjust tag with desired version if applicable. | ||
| uses: python-semantic-release/python-semantic-release@b700dbeb1f431a0fcc30a79f3f0869407fe07278 # v10.7.0 | ||
| with: | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} | ||
| git_committer_name: "github-actions" | ||
| git_committer_email: "actions@users.noreply.github.com" | ||
| changelog: "false" | ||
| # Commit, tag, push and build, but don't create the GitHub release. | ||
| # We create it ourselves in the next step so that the distributions | ||
| # are attached before the release is published. See that step for why. | ||
| vcs_release: "false" | ||
|
|
||
| # This repo has immutable releases enabled, which freezes a release's | ||
| # assets the moment it is published, so assets cannot be attached | ||
| # afterwards. Everything we want on the release has to be built by now | ||
| # and passed to this one command, which creates the release as a draft, | ||
| # uploads the assets, and only then publishes it: | ||
| # https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases | ||
| - name: Publish | Create GitHub Release with Assets | ||
| if: steps.release.outputs.released == 'true' | ||
| env: | ||
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| # Reuse the release notes python-semantic-release generated for us. | ||
| RELEASE_NOTES: ${{ steps.release.outputs.release_notes }} | ||
| TAG: ${{ steps.release.outputs.tag }} | ||
| run: | | ||
| # Output the release notes to a file | ||
| printf '%s' "$RELEASE_NOTES" > "$RUNNER_TEMP/release_notes.md" | ||
| # Creates the release as a draft, uploads the assets, and then | ||
| # publishes it -- all within this one command. | ||
| gh release create "$TAG" \ | ||
| --verify-tag \ | ||
| --title "$TAG" \ | ||
| --notes-file "$RUNNER_TEMP/release_notes.md" \ | ||
| dist/* | ||
|
|
||
| - name: Upload | Distribution Artifacts | ||
| uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2 | ||
| if: steps.release.outputs.released == 'true' | ||
| with: | ||
| name: distribution-artifacts | ||
| path: dist | ||
| if-no-files-found: error | ||
|
|
||
| outputs: | ||
| released: ${{ steps.release.outputs.released || 'false' }} | ||
| version: ${{ steps.release.outputs.version }} | ||
|
|
||
| publish_to_pypi: | ||
| # 1. Separate out the publish step from the github release step to run each step at | ||
| # the least amount of token privilege | ||
| # 2. Also, publishing can fail, and its better to have a separate job if you need to retry | ||
| # and it won't require reversing the release. | ||
| runs-on: ubuntu-latest | ||
| needs: release | ||
| if: github.ref_name == 'master' && needs.release.outputs.released == 'true' | ||
|
|
||
| permissions: | ||
| contents: read | ||
| id-token: write | ||
|
|
||
| steps: | ||
| - name: Setup | Download Build Artifacts | ||
| uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2 | ||
| id: artifact-download | ||
| with: | ||
| name: distribution-artifacts | ||
| path: dist | ||
|
|
||
| - name: Publish to PyPi | ||
| uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2 | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,7 +1,4 @@ | ||
| include CHANGELOG.rst | ||
| include LICENSE | ||
| include README.rst | ||
| include requirements/base.in | ||
| include requirements/test.in | ||
| recursive-include completion *.html *.png *.gif *js *.css *jpg *jpeg *svg *py | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The sdist grew from 60 files in 5.0.0 to 100 here. setuptools-scm adds every git-tracked file, so it now ships
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd keep this out of the migration PR. None of the merged migrations added sdist excludes, so it fits better as a separate follow-up. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the context! Since this PR switches to setuptools-scm and that's what pulls the extra files into the sdist, I think it'd be nice to keep parity with master here. The earlier migrations probably just missed it. Maybe we can start adding the excludes in the open and upcoming PRs, and pick up the merged repos during the backporting cycle? |
||
| include requirements/constraints.txt | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
run_cicallsci.ymlwithoutsecrets: inherit, so on master pushes the Codecov step runs withoutCODECOV_TOKEN, and it hasfail_ci_if_error: true. sample-plugin and XBlock are set up the same way, so tokenless upload is probably fine, but has this been confirmed? If the upload fails,releasewon't run.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, openedx-chem has the same setup (no
secrets: inherit,fail_ci_if_error: true) and the Codecov upload passed in its v2.0.1 release run.