fix: update Gitea token reference in documentation and workflows to use RELEASE_TOKEN
This commit is contained in:
@@ -44,7 +44,12 @@ jobs:
|
|||||||
env:
|
env:
|
||||||
GITEA_URL: ${{ github.server_url }}
|
GITEA_URL: ${{ github.server_url }}
|
||||||
GITEA_REPOSITORY: ${{ github.repository }}
|
GITEA_REPOSITORY: ${{ github.repository }}
|
||||||
GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
|
# Secret is named RELEASE_TOKEN, not GITEA_TOKEN: Gitea rejects any
|
||||||
|
# secret name starting with GITEA_ or GITHUB_, since both prefixes
|
||||||
|
# are reserved for its own built-in variables. The env var on the
|
||||||
|
# left is unaffected — that's just the name publish_gitea.py reads
|
||||||
|
# from os.environ, and can be anything.
|
||||||
|
GITEA_TOKEN: ${{ secrets.RELEASE_TOKEN }}
|
||||||
# Leaves a draft. Review the archives, then publish from the web UI, or
|
# Leaves a draft. Review the archives, then publish from the web UI, or
|
||||||
# add --publish here once you trust the pipeline.
|
# add --publish here once you trust the pipeline.
|
||||||
run: >-
|
run: >-
|
||||||
|
|||||||
@@ -502,7 +502,7 @@ git tag v2.0.0 && git push origin v2.0.0
|
|||||||
The Gitea one needs only a single runner because the cross-build makes the
|
The Gitea one needs only a single runner because the cross-build makes the
|
||||||
archives independent of build host — see
|
archives independent of build host — see
|
||||||
[packaging/GITEA-SETUP.md](packaging/GITEA-SETUP.md) for runner registration and
|
[packaging/GITEA-SETUP.md](packaging/GITEA-SETUP.md) for runner registration and
|
||||||
the `GITEA_TOKEN` secret. `publish_gitea.py` is stdlib-only and idempotent:
|
the `RELEASE_TOKEN` secret. `publish_gitea.py` is stdlib-only and idempotent:
|
||||||
re-running on the same tag replaces assets rather than duplicating them.
|
re-running on the same tag replaces assets rather than duplicating them.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|||||||
@@ -65,9 +65,19 @@ that only serves this purpose, worth knowing about regardless.
|
|||||||
Releases are published through Gitea's own API by
|
Releases are published through Gitea's own API by
|
||||||
`packaging/publish_gitea.py`, so the job needs a token:
|
`packaging/publish_gitea.py`, so the job needs a token:
|
||||||
|
|
||||||
1. **Settings → Applications → Generate New Token**, scope `write:repository`.
|
1. **Settings → Applications → Generate New Token.** Give it a name, leave
|
||||||
|
everything at *No Access* except **repository**, set to *Read and Write*.
|
||||||
|
Copy the value shown — Gitea displays it exactly once.
|
||||||
2. In the repository: **Settings → Actions → Secrets → Add Secret**, named
|
2. In the repository: **Settings → Actions → Secrets → Add Secret**, named
|
||||||
`GITEA_TOKEN`.
|
`RELEASE_TOKEN`, value the token from step 1.
|
||||||
|
|
||||||
|
Not `GITEA_TOKEN`. Gitea rejects any secret name starting with `GITEA_` or
|
||||||
|
`GITHUB_` — both prefixes are reserved for its own built-in variables, and
|
||||||
|
the validation pattern is exactly `^(?!GITEA_|GITHUB_)[a-zA-Z_][a-zA-Z0-9_]*$`.
|
||||||
|
`release.yml` reads `secrets.RELEASE_TOKEN` and maps it to a
|
||||||
|
`GITEA_TOKEN` environment variable inside the job — that env var name is
|
||||||
|
unrelated to the secret name and can be anything, since it's just what
|
||||||
|
`publish_gitea.py` reads from `os.environ`.
|
||||||
|
|
||||||
`GITEA_URL` and `GITEA_REPOSITORY` come from `github.server_url` and
|
`GITEA_URL` and `GITEA_REPOSITORY` come from `github.server_url` and
|
||||||
`github.repository`, which Gitea populates for compatibility. Nothing else to
|
`github.repository`, which Gitea populates for compatibility. Nothing else to
|
||||||
|
|||||||
+18
-3
@@ -69,15 +69,30 @@ EOF
|
|||||||
exit 1
|
exit 1
|
||||||
fi
|
fi
|
||||||
|
|
||||||
|
# llama-cpp-python ships only an sdist to PyPI, so a plain install compiles
|
||||||
|
# it from source. On Linux that means a full toolchain and a long wait, and
|
||||||
|
# the upstream index below carries prebuilt manylinux wheels instead.
|
||||||
|
#
|
||||||
|
# Deliberately NOT used on macOS. The PyPI wheel there already carries
|
||||||
|
# Metal support, and adding a CPU-only index risks pip picking it on a tie,
|
||||||
|
# quietly costing every Apple Silicon user their GPU for no visible reason.
|
||||||
|
if [ "$(uname -s)" = "Linux" ]; then
|
||||||
|
PIP_INDEX="--extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu"
|
||||||
|
else
|
||||||
|
PIP_INDEX=""
|
||||||
|
fi
|
||||||
|
|
||||||
echo "Installing dependencies..."
|
echo "Installing dependencies..."
|
||||||
"$VENV/bin/python" -m pip install --quiet --upgrade pip
|
"$VENV/bin/python" -m pip install --quiet --upgrade pip
|
||||||
if ! "$VENV/bin/python" -m pip install -r "$HERE/requirements.txt"; then
|
# shellcheck disable=SC2086 # intentional word splitting; the URL has no spaces
|
||||||
|
if ! "$VENV/bin/python" -m pip install $PIP_INDEX -r "$HERE/requirements.txt"; then
|
||||||
cat >&2 <<EOF
|
cat >&2 <<EOF
|
||||||
|
|
||||||
Dependency installation failed.
|
Dependency installation failed.
|
||||||
|
|
||||||
The usual culprit is llama-cpp-python, which compiles from source when no
|
If the error above mentions llama-cpp-python, cmake or a missing compiler,
|
||||||
prebuilt wheel matches this platform. It needs a C compiler:
|
then pip found no prebuilt wheel and fell back to building from source. That
|
||||||
|
needs a C toolchain:
|
||||||
|
|
||||||
macOS xcode-select --install
|
macOS xcode-select --install
|
||||||
Linux sudo apt install build-essential cmake
|
Linux sudo apt install build-essential cmake
|
||||||
|
|||||||
Reference in New Issue
Block a user