From 117181d645775abc08b716277df6452e493f86f6 Mon Sep 17 00:00:00 2001 From: Alejandro Rosas Date: Thu, 29 Oct 2026 16:53:26 +0400 Subject: [PATCH 1/3] ci(release): publish every release automatically, with no stored token release-please now runs on every push to main, so merging the release pull request creates the tag and the release. A release created with GITHUB_TOKEN does not trigger the release event, so release-please starts release.yml for the new tag with workflow_dispatch, which GITHUB_TOKEN may trigger. release.yml accepts the tag as an input as well as the release event. Registries use trusted publishing, so no publishing token is stored. Co-Authored-By: Claude Opus 5.5 --- .github/workflows/release-please.yml | 32 +++++++++++++++------------- .github/workflows/release.yml | 21 ++++++++++-------- 2 files changed, 29 insertions(+), 24 deletions(-) diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml index 1e6a527..ce71b8c 100644 --- a/.github/workflows/release-please.yml +++ b/.github/workflows/release-please.yml @@ -1,20 +1,12 @@ -# NOTHING MAY BE PUBLISHED before Alex's explicit approval and the 2026-11-01 Didit release -# (docs/DESIGN.md section 13). The PyPI environment `pypi` used by release.yml must require -# a reviewer. -# -# release-please opens the release pull request (version bump and the generated -# CHANGELOG.md) and, once that pull request is merged and this workflow runs again, creates -# the tag and the GitHub release, which starts release.yml. It runs only when started by -# hand, so nothing is cut by accident. -# -# Token: a release or pull request created with the default GITHUB_TOKEN does not trigger -# other workflows, so release.yml would not start and the release pull request would get -# no CI. Add a repository secret RELEASE_PLEASE_TOKEN (a fine-grained token with Contents, -# Issues and Pull requests read and write on this repository only) to fix that; without it -# the workflow falls back to GITHUB_TOKEN. +# release-please keeps the release pull request (version bump and the generated CHANGELOG.md) +# up to date on every push to main. Merging that pull request makes the next run create the +# vX.Y.Z tag and the GitHub release and then start release.yml for that tag, which publishes +# to PyPI with trusted publishing. No stored token is needed: everything runs on GITHUB_TOKEN. name: Release Please on: + push: + branches: [main] workflow_dispatch: permissions: @@ -30,13 +22,23 @@ jobs: runs-on: ubuntu-latest timeout-minutes: 10 permissions: + actions: write # start release.yml contents: write issues: write pull-requests: write steps: - name: Run release-please + id: release uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0 with: - token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }} + token: ${{ secrets.GITHUB_TOKEN }} config-file: release-please-config.json manifest-file: .release-please-manifest.json + - name: Publish the release + # A release created with GITHUB_TOKEN does not trigger the `release` event, so start + # release.yml for the new tag directly (workflow_dispatch is allowed with GITHUB_TOKEN). + if: ${{ steps.release.outputs.release_created == 'true' }} + env: + GH_TOKEN: ${{ github.token }} + TAG: ${{ steps.release.outputs.tag_name }} + run: gh workflow run release.yml --repo "$GITHUB_REPOSITORY" --ref "$TAG" -f tag="$TAG" diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index f3cdbd9..3c4e39a 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -1,21 +1,24 @@ -# NOTHING MAY BE PUBLISHED before Alex's explicit approval and the 2026-11-01 Didit release -# (docs/DESIGN.md section 13). The GitHub environment `pypi` must require a reviewer, so -# that every upload to PyPI waits for an explicit approval. -# -# Publishes didit-sdk to PyPI with trusted publishing (OIDC, no API token) when a GitHub -# release is published. The PyPI project must list this repository, the workflow +# Publishes didit-sdk to PyPI with trusted publishing (OIDC, no API token). It runs when +# release-please creates a release (release-please.yml starts it with the tag) or when a +# GitHub release is published by hand. The PyPI project lists this repository, the workflow # release.yml and the environment pypi as a trusted publisher. name: Release on: release: types: [published] + workflow_dispatch: + inputs: + tag: + description: Release tag to publish (for example v1.2.0); release-please starts this run + required: true + type: string permissions: contents: read concurrency: - group: release-${{ github.event.release.tag_name }} + group: release-${{ github.event.release.tag_name || inputs.tag }} cancel-in-progress: false defaults: @@ -31,6 +34,7 @@ jobs: - name: Check out the release tag uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 with: + ref: ${{ github.event.release.tag_name || inputs.tag }} persist-credentials: false - name: Set up uv uses: astral-sh/setup-uv@18d369b23da25a81e9458561248e1aafff6a70fa # v10.3.1 @@ -39,7 +43,7 @@ jobs: enable-cache: false - name: Check that the release tag matches the package version env: - RELEASE_TAG: ${{ github.event.release.tag_name }} + RELEASE_TAG: ${{ github.event.release.tag_name || inputs.tag }} run: | uv run --no-project python - <<'PY' import os @@ -91,7 +95,6 @@ jobs: runs-on: ubuntu-latest timeout-minutes: 10 environment: - # Must require a reviewer (Settings > Environments > pypi > Required reviewers). name: pypi url: https://pypi.org/project/didit-sdk/ permissions: From 0495bfed9a4111ea51af4bab8880f7c3ed4dce8f Mon Sep 17 00:00:00 2001 From: Alejandro Rosas Date: Thu, 29 Oct 2026 17:02:39 +0400 Subject: [PATCH 2/3] docs(release): releases publish straight from the repository Alex approved the 1.0.0 release on 2026-10-29 and asked that every release publish straight from the repository. The pre-launch rule (no tag or publish before 2026-11-01 without his approval) is replaced: merging the release-please pull request is the release approval. docs/DESIGN.md section 13 records the same, identically in all seven SDK repositories. Co-Authored-By: Claude Opus 5.5 --- AGENTS.md | 2 +- CLAUDE.md | 2 +- docs/DESIGN.md | 7 ++++--- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index a21ea35..84b6798 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -39,7 +39,7 @@ uv for environments and locking, hatchling for the build, pytest, mypy --strict, - `openapi/verification.json`, `openapi/account.json` and `openapi/webhook-vectors.json` are upstream copies; never edit them by hand. Only the spec sync workflow updates them. - Keep the SDKs in sync (HARD RULE). Any public API change in `service-didit-verification` or `service-didit-auth` must reach the OpenAPI documents in mintlify-docs, and from there every server SDK through the spec sync pull request. A change to hand-written core behaviour that DESIGN.md describes (client options, errors, retries, pagination, webhooks, Authentication) is made in all seven SDK repositories, one pull request each, and DESIGN.md is updated in all seven in the same words. - Feature parity across languages: a capability shipped in one server SDK ships in the other six. -- Never publish a package, push a release tag or make this repository public without Alex's explicit approval; nothing is released before the 2026-11-01 Didit release. +- Releases publish straight from this repository (Alex, 2026-10-29): merging the release-please pull request is the release approval, and the release workflow then creates the vX.Y.Z tag and publishes to the registry. Never push a release tag, create a release or publish by hand outside that flow, and never store a registry token where trusted publishing works. - Unit tests never touch the network. Live smoke tests run only when `DIDIT_SANDBOX_API_KEY` is set. - Never commit secrets, API keys or real customer data. Fixtures are synthetic. - `CHANGELOG.md` is generated by release-please from conventional commits; never edit it by hand. diff --git a/CLAUDE.md b/CLAUDE.md index a21ea35..84b6798 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -39,7 +39,7 @@ uv for environments and locking, hatchling for the build, pytest, mypy --strict, - `openapi/verification.json`, `openapi/account.json` and `openapi/webhook-vectors.json` are upstream copies; never edit them by hand. Only the spec sync workflow updates them. - Keep the SDKs in sync (HARD RULE). Any public API change in `service-didit-verification` or `service-didit-auth` must reach the OpenAPI documents in mintlify-docs, and from there every server SDK through the spec sync pull request. A change to hand-written core behaviour that DESIGN.md describes (client options, errors, retries, pagination, webhooks, Authentication) is made in all seven SDK repositories, one pull request each, and DESIGN.md is updated in all seven in the same words. - Feature parity across languages: a capability shipped in one server SDK ships in the other six. -- Never publish a package, push a release tag or make this repository public without Alex's explicit approval; nothing is released before the 2026-11-01 Didit release. +- Releases publish straight from this repository (Alex, 2026-10-29): merging the release-please pull request is the release approval, and the release workflow then creates the vX.Y.Z tag and publishes to the registry. Never push a release tag, create a release or publish by hand outside that flow, and never store a registry token where trusted publishing works. - Unit tests never touch the network. Live smoke tests run only when `DIDIT_SANDBOX_API_KEY` is set. - Never commit secrets, API keys or real customer data. Fixtures are synthetic. - `CHANGELOG.md` is generated by release-please from conventional commits; never edit it by hand. diff --git a/docs/DESIGN.md b/docs/DESIGN.md index dfd5287..f4bffe4 100644 --- a/docs/DESIGN.md +++ b/docs/DESIGN.md @@ -247,9 +247,10 @@ Ruby: `net/http` from the standard library, `jwt` only for Authentication. - Semantic versioning; a breaking change to the public SDK surface is a major version. - Releases are cut by release-please from conventional commits; `CHANGELOG.md` is generated and never edited by hand. -- Release workflows publish with trusted publishing or provenance where the registry supports it (PyPI and RubyGems trusted publishing, npm provenance, Maven Central via the Central Portal with signed artifacts, NuGet with a scoped key and the `Didit` prefix reserved, Packagist auto-update from tags, Go module tags). -- Nothing is published before Alex approves the first release, and not before the 2026-11-01 release; until then versions stay `0.x` pre-release in the repository. -- The repository stays private until that first release. +- Release workflows publish with trusted publishing where the registry supports it (PyPI, npm with provenance, RubyGems and NuGet), Maven Central through the Central Portal with signed artifacts (token and signing key in the `maven-central` environment), Packagist through its GitHub hook, and Go module tags announced to proxy.golang.org. +- 1.0.0 shipped on 2026-10-29 with Alex's approval, and the repositories are public. +- Every release after that publishes straight from the repository: merging the release-please pull request is the approval, and the workflow creates the vX.Y.Z tag and publishes. +- A release created with `GITHUB_TOKEN` does not trigger other workflows, so a repository that publishes from a separate `release.yml` has release-please start it with `workflow_dispatch` for the new tag. No personal access token is stored. ## 14. Documentation and positioning From b867c80dbfeadee9c4c2876591e8bd1e3c1c23a3 Mon Sep 17 00:00:00 2001 From: Alejandro Rosas Date: Thu, 29 Oct 2026 17:14:53 +0400 Subject: [PATCH 3/3] docs(release): drop the pre-launch release policy everywhere The SDK is released (1.0.0 on 2026-10-29) and merging the release pull request is the release approval, so the leftover pre-launch text is replaced: the README banners, the agent status line, the CONTRIBUTING release sections and the workflow comments no longer describe a private, unreleased repository or a reviewer gate on the publish environments (which have no required reviewers). docs/DESIGN.md section 2.1 records the completed didit-sdk PyPI transfer and the terms agreed with Agustin Saiz, identically in all seven repositories. Co-Authored-By: Claude Opus 5.5 --- AGENTS.md | 2 +- CLAUDE.md | 2 +- CONTRIBUTING.md | 4 ++-- README.md | 2 -- docs/DESIGN.md | 5 ++--- 5 files changed, 6 insertions(+), 9 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 84b6798..df8323b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,7 +1,7 @@ # Didit Python SDK (`sdk-python`) The official Didit server-side library for Python: `didit-sdk` on PyPI (name transfer pending, see docs/DESIGN.md 2.1). -Status: in development, not released. +Status: released (1.0.0 on 2026-10-29). Merging the release-please pull request publishes the next version. ## Read first diff --git a/CLAUDE.md b/CLAUDE.md index 84b6798..df8323b 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,7 +1,7 @@ # Didit Python SDK (`sdk-python`) The official Didit server-side library for Python: `didit-sdk` on PyPI (name transfer pending, see docs/DESIGN.md 2.1). -Status: in development, not released. +Status: released (1.0.0 on 2026-10-29). Merging the release-please pull request publishes the next version. ## Read first diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3f0b492..2087317 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -74,9 +74,9 @@ They never run in the default CI. A maintainer can start them from the CI workfl Pull request titles and commits follow [Conventional Commits](https://www.conventionalcommits.org/): `fix:` is a patch, `feat:` a minor version, and `feat!:` or a `BREAKING CHANGE:` footer a major version (a minor version while the SDK is 0.x). Pick the type that matches the semver impact of the change. -Releases are cut by release-please from those commits. It updates the version and generates `CHANGELOG.md`; never edit the changelog by hand. Squash-merge pull requests so that their conventional title becomes the commit release-please reads. `.release-please-manifest.json` holds the version in the repository (0.1.0, unreleased). The first public release sets its version with a `Release-As: ` footer in a commit on `main`. +Releases are cut by release-please from those commits. It updates the version and generates `CHANGELOG.md`; never edit the changelog by hand. Squash-merge pull requests so that their conventional title becomes the commit release-please reads. `.release-please-manifest.json` holds the released version. -Nothing is published without Alex's explicit approval, and nothing before the 2026-11-01 Didit release. Do not push release tags or publish packages. +release-please runs on every push to `main`. Merging the release pull request is the release approval (Alex, 2026-10-29); nobody tags or publishes by hand. The next run creates the `vX.Y.Z` tag and the GitHub release and starts `release.yml`, which publishes to PyPI with trusted publishing (no stored token). ## Keep the SDKs in sync diff --git a/README.md b/README.md index 92d5665..697cd7b 100644 --- a/README.md +++ b/README.md @@ -2,8 +2,6 @@ The official Didit Python library: identity verification (KYC), business verification (KYB), AML screening, biometrics, transaction monitoring, Travel Rule and customer authentication, from your Python backend. -> In development, not released yet. The package will be published on PyPI as `didit-sdk` with the first release. - - Every server-side endpoint of the Didit API, with typed requests and responses - `Didit` (blocking) and `AsyncDidit` (asyncio) clients with the same methods - Webhook verification with every Didit signature scheme, and typed events diff --git a/docs/DESIGN.md b/docs/DESIGN.md index f4bffe4..32996e0 100644 --- a/docs/DESIGN.md +++ b/docs/DESIGN.md @@ -33,9 +33,8 @@ The Maven group `me.didit` is the one `sdk-android` already publishes under. PyPI `didit` belongs to an unrelated project from 2013. PyPI `didit-sdk` is a community package by Agustin Saiz (MIT, unofficial, sessions only). -Didit is asking him to transfer the `didit-sdk` project to Didit, so the official SDK ships under that name. -Until the transfer is confirmed, keep `didit-sdk` as the distribution name in `pyproject.toml` and do not publish. -The fallback name, if the transfer does not happen, is `didit-python`. +He transferred the `didit-sdk` project to Didit, and the official SDK published 1.0.0 under that name on 2026-10-29. +As agreed with him, his releases 0.1.0 to 0.4.0 stay published, his PyPI user stays on the project, and the 1.0.0 release notes credit the initial community versions. ## 3. Source of truth: the OpenAPI contract