Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Release from a tag: CI builds and publishes, with one tag style across the three libraries

Aperta
  • Qualcosa non va?
#158 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github-actions, python
Ambito
ci-cd, devops, release

Direzione di ricerca

Start by reading pyproject.toml for the project version and build configuration, then inspect the repository’s existing GitHub Actions workflows and release process. Implement and document the tag-triggered release flow described in the issue, including the version check, wheel smoke test, and trusted publishing setup. Done means a test tag completes the dry run, RELEASING.md is merged, and the required secrets or publisher configuration are documented for the maintainer.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

The 0.3.0 / 3.3.0 / 0.2.0 releases were built and tagged by hand, and they drifted. drivine4j was published from main past its release PR, so its tag had to follow what was published. drivine nearly went out from a checkout with a stale node_modules. The tag styles also differ (0.3.0 in drivine4j, vX.Y.Z in the others).

The same release process for all three libraries:

  1. A release PR bumps the version and the changelog. It is reviewed and passes CI like any other PR.
  2. Merging it is the release point. The merge commit is tagged vX.Y.Z, the same style in all three repos.
  3. A tag push runs a GitHub Actions workflow that checks out the tag, runs the full gate, builds, and publishes. Nothing is built from a local checkout.
  4. Credentials live as repo secrets (or trusted publishing), never on a laptop.
  5. RELEASING.md describes the steps. Each repo has the same file, differing only in its publish step.

Done when:

  • a dry run (to a staging target or with publish skipped) works from a test tag;
  • RELEASING.md is merged;
  • the secrets are listed for the maintainer to add.

Use it for the next release, once the "Next release + 1" backlog is cleared.

drivine-python specifics:

  • Publish: uv build (hatchling), then upload to PyPI with trusted publishing (OIDC); no token needed.
  • Setup: configure a PyPI trusted publisher for the repo and workflow.
  • Check: pyproject.toml's version matches the tag, or the job fails.
  • Smoke test: after the build, install the wheel into a clean venv and run python -m drivine.stubs.
Lingua principale
Python
Stelle
1
Fork
0
Merge medio
1h 16m
PR unite (30g)
74

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di liberation-data/drivine-python

Tutte le issue di liberation-data/drivine-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.