tao.chen/notebook-snapshot-extension
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
11 Commits 1 Branch 1 Tag
ac17a954b01c1d7a945367788583b5fa62f5a4b4
Commit Graph
5 Commits
Author SHA1 Message Date
tao.chenandClaude ac17a954b0 ci: extract release script to fix YAML parse error (line 51)
CI / CI (push) Canceled after 11m29s
Details 
The 'Upload release assets via Gitea API' step embedded a JSON
heredoc inside a YAML block scalar (run: |). Gitea's YAML parser
bailed at line 51 with 'could not find expected :'' when it saw
the leading '{' of the JSON body — it tried to interpret the
heredoc content as a flow mapping instead of literal text.

Fix: move the release logic into .github/scripts/create-release.sh
and pass the GitHub Actions context values as env vars. The step
becomes:

  env:
    GITEA_TOKEN: ...
    TAG_NAME: ...
    API_URL: ...
    REPOSITORY: ...
    SHA: ...
  run: ./.github/scripts/create-release.sh

Validates cleanly with PyYAML (yaml.safe_load). Pattern matches
bark-notify.sh from earlier — CI helpers live in .github/scripts/,
workflows stay slim.

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-07-21 18:57:18 +08:00
tao.chenandClaude 72fd363600 ci: move bark-notify.sh to .github/scripts, add Gitea release asset upload 
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>
 2026-07-21 18:51:57 +08:00
tao.chenandClaude 044c83cd22 ci: bark notification on build success / failure 
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>
 2026-07-21 18:50:25 +08:00
tao.chenandClaude 121b835494 ci: rewrite workflows for Gitea, use astral-uv runner, uv build only 
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>
 2026-07-21 18:48:15 +08:00
tao.chenandClaude cd1aba6698 dev: initial implementation of notebook-snapshot extension 
Manual-commit notebook snapshot extension (JupyterLab 4):

Backend
- Storage adapter layer (Local + S3 via boto3, pip extra)
  - Dumb put/get/list/delete contract; key validation
  - S3Storage: lazy boto3 import, S3ConnectionError with friendly
    messages + connectivity check at startup
- SnapshotStore
  - Strip code outputs/execution_count, MD5 on cleaned JSON
  - Gzipped envelope (id/timestamp/name/description/hash/size/notebook)
  - Append-only manifest.json (rebuildable from version files)
  - SnapshotUnchangedError when new hash matches most recent version
- REST API (commit / list / content) under /snapshot/ namespace
- traitlets config (storage_type, local_root, s3_* + S3_* env fallback)

Frontend
- snapshot:commit command (toolbar button + command palette)
- Dialog for name + description
- SnapshotPanel (left sidebar timeline) + DiffWidget (main area)
- Cell diff: id-match first, LCS fallback; jsdiff for line diff
- Restore via model.fromJSON() + context.save() (no refresh)
- All AGENTS.md hard conventions enforced

Tests: 33 backend pytest passing (storage + store + routes)

Docs: AGENTS.md, design.md, README.md synced with implementation.

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-07-21 17:33:55 +08:00