Two changes:
1. Move scripts/bark-notify.sh -> .github/scripts/bark-notify.sh
(CI helper belongs next to the workflow that calls it). History
preserved via git mv.
2. Add a 'Upload release assets via Gitea API' step that runs only
on tag pushes (if: startsWith(github.ref, 'refs/tags/v')). It:
- POSTs /releases to create a Gitea release bound to the tag
- extracts the release id from the response (with explicit error
path if the API call fails)
- loops over dist/snapshot-*.whl and dist/snapshot-*.tar.gz and
uploads each as a release asset
Uses ${{ secrets.GITHUB_TOKEN }} exposed as the GITEA_TOKEN env
var (the Gitea convention for the repo token secret). The
Notify Bark step still runs last with if: always() so a release
upload failure is reported via the phone.
Co-Authored-By: Claude <noreply@anthropic.com>
Adds scripts/bark-notify.sh (deployment detail, hardcoded
device_key + endpoint — per the script header it's a deployment
constant, not a secret) and a final workflow step that pushes
a ✅/❌ notification on every job result.
The notify step:
- runs unconditionally (if: always()) so failures also notify
- is a side-effect — if Bark itself is unreachable, the
curl failure is swallowed so CI does not turn red on a
notification outage
- uses portable context vars (github.repository / ref_name /
sha / actor / job.status) which work on Gitea Actions
Co-Authored-By: Claude <noreply@anthropic.com>
Replaces the previous five JupyterLab-template workflows
(build / check-release / enforce-label / prep-release /
publish-release / update-integration-tests) with a single minimal
CI workflow tuned for a self-hosted Gitea runner.
What's in the new build.yml:
- Triggers: push to main, push of v* tag, pull_request
- runs-on: astral-uv (self-hosted runner with uv pre-installed;
we skip the setup-uv step)
- Steps: checkout -> uv build -> upload-artifact
- uv build alone is enough because pyproject.toml's
[tool.hatch.build.hooks.jupyter-builder] drives jlpm install
and jlpm build:prod before wheel assembly, and uv caches the
build environment between runs.
What's removed: all jupyter-server/jupyter_releaser steps and the
check-links / update-snapshots / test_isolated / integration-tests
jobs from the template — they depended on jupyterlab/maintainer-tools
and GitHub-specific secrets (GITHUB_TOKEN, APP_PRIVATE_KEY, NPM_TOKEN)
that don't apply to a Gitea deployment.
Co-Authored-By: Claude <noreply@anthropic.com>
