3 Releases 9 Tags

RSS Feed

• v0.7.0 6fab30337a

  Compare

  ReleaseKit v0.7.0 Stable

  eric released this 2026-11-02 14:00:17 +00:00 | 0 commits to main since this release

  ReleaseKit v0.7.0

  Summary

  ReleaseKit improves source-publication integrity, cancellation, credential-safe
  diagnostics, partial-result reporting, and temporary-file cleanup. It also bounds
  retained Go failure diagnostics and remote attachment comparison work while
  preserving the existing public facades and configuration formats.

  Publication and Git operations

  • Exact tag pushes disable submodule recursion, correcting inherited
    push.recurseSubmodules=only settings that could report success without
    publishing the release tag.
  • ReleaseKit-owned Git inspection and preparation use original objects when
    replacement refs exist. Committed module identity, release notes, validation
    inputs, and build source eligibility use that consistent view. Ordinary dirty
    builds remain supported, with their source eligibility reported separately.
  • A verified local tag object remains available in PublicationResult.TagObject
    when later inspection fails. Errors identify a possibly retained local ref
    when its object ID could not be established. Failed verification stops before
    a push.
  • HTTP(S) userinfo is masked in owned Git diagnostics and CLI output, including
    literal apostrophes in credentials and failed CI checkout preparation. Native
    Git authentication, exact endpoint comparisons, and the raw captured
    PublicationResult.Endpoint value retain their existing behavior.
  • Child environment overlays preserve the working-directory-derived PWD on
    POSIX systems. Native Git hooks now receive the expected directory environment
    when ReleaseKit is invoked from another checkout or module subdirectory.

  Cancellation and diagnostic retention

  • Buffered subprocess output has bounded I/O teardown after cancellation or
    child exit, including when descendants retain inherited output descriptors.
    Piped Git-reader cancellation closes owned pipes and joins child cleanup.
    Cancellation remains recognizable through errors.Is; ordinary execution
    failures preserve their underlying causes.
  • A queued blob read rechecks cancellation after acquiring the reader mutex,
    preserving a healthy batch session for later reads.
  • Status-only Go commands and dependency preparation retain a 1 MiB diagnostic
    tail. Failed commands identify omitted earlier output. Existing streaming
    output continues to be forwarded in full, and commands requiring returned
    output keep their complete capture.

  Builds and hosted delivery

  • Completed build artifacts are reported only after hashing succeeds. A hashing
    failure identifies the affected output and preserves earlier completed
    artifacts and their digests.
  • Temporary allocation and cleanup failures retain their paths and underlying
    causes, including candidate builds, native version checks, delivery builds,
    tag-message files, and build receipts.
  • A managed-build cleanup failure after confirmed hosted delivery returns an
    error alongside DeliveryComplete and the confirmed asset observations. The
    CLI reports completed remote work and the local cleanup failure, returning
    operational status 1.
  • Gitea attachment downloads follow at most ten redirects, retaining cycle
    detection and per-origin authorization handling. Limit exhaustion is
    unverifiable content.
  • Remote attachment comparison reads at most the locally verified expected size
    plus one byte. Shorter or longer content conflicts; equal-length content still
    requires the expected digest. Read, close, and cancellation errors remain
    inspection failures, with existing attempted-write reconciliation preserved.

  Shared Git observations, validation sequencing, artifact declaration matching,
  and CLI workflows were consolidated internally. Consumer-facing types continue
  to belong to the root releasekit and runtime buildinfo facades.

  Compatibility and upgrade guidance

  The module identifier remains go.maximumdirect.net/releasekit, and the Go
  consumer minimum remains 1.26.0. Existing v0.6.0 API calls, profile fields, and
  build receipt formats remain supported. This minor release changes operational
  behavior through the diagnostic and redirect budgets and cleanup-error reporting
  described above.

  When adopting v0.7.0:

  1. Update library and CLI dependencies to v0.7.0 using the existing import paths
     and profiles.
  2. Handle a delivery error together with DeliveryResult.State. For
     DeliveryComplete, address the reported local cleanup path; the confirmed
     hosted delivery is already complete. Continue to resolve partial, conflicting,
     and unknown outcomes through their existing recovery guidance.
  3. Retain candidate validation's streamed Output when complete test diagnostics
     are needed. Status-only failure text now contains the retained tail and an
     omission notice when applicable.
  4. When using Git replacement refs, expect release evidence to be evaluated
     against original committed objects. A build of dirty or replacement-derived
     working content can succeed while remaining ineligible for binary delivery.
  5. Inspect the reported local tag ref after a tag-creation or verification
     failure, including when TagObject is empty. Continue to treat the raw
     PublicationResult.Endpoint as sensitive when handling it in application
     output or logs.

  See the publication guide,
  build guide,
  delivery guide,
  CLI contract,
  and Gitea integration guide
  for current behavior. Source publication and hosted delivery retain their
  separate outcomes under the maintainer procedure.

  COPYRIGHT |
  LICENSE |
  ATTRIBUTION

  Downloads

  • Source Code (ZIP)
  • Source Code (TAR.GZ)
• v0.6.0 dd0a557ad3

  Compare

  ReleaseKit v0.6.0 Stable

  eric released this 2026-11-01 23:43:20 +00:00 | 39 commits to main since this release

  ReleaseKit v0.6.0

  Summary

  ReleaseKit adds file-based delivery credentials, optional checks for forbidden
  committed files, neutral delivery coordination with explicit Gitea selection, and
  authenticated, read-only credential preflight. It also corrects dependency
  preparation, publication recovery, and build cancellation handling.

  Changes

  • Delivery profiles can select a plain token file through token_file.
    Relative paths resolve from the checkout root; a nonblank token environment
    value takes precedence. The CLI trims file contents and reports unreadable
    or blank files as credential-loading failures. Library callers continue to
    supply the token explicitly through the destination.
  • ValidationSpec.ForbiddenFiles and validation.forbidden_files select
    literal repository-relative paths that must be absent from the committed
    candidate. This optional check can protect a local token-file path. It
    inspects committed path metadata independently of module/shared-file inputs;
    it does not inspect file contents or history.
  • releasekit.DeliveryRequest.Destination now uses the facade-owned
    releasekit.DeliveryDestination. Set Forge: releasekit.ForgeGitea for
    Gitea delivery. The removed GiteaDestination type has no compatibility
    alias.
  • Delivery profiles must include "forge": "gitea". The selection is
    required only when deliver or ci-deliver is requested; the URL does not
    infer a backend. check, build, and source publish remain independent of
    delivery selection and credentials.
  • releasekit.PreflightDelivery allows callers to check a destination without
    a checkout or tag. Deliver performs the same read-only preflight
    automatically. For Gitea, the check authenticates through repository-scoped
    reads and makes no test release or asset writes.
  • DeliveryPreflightError exposes classified failures and retains the
    underlying cause. Successful preflight confirms authentication and repository
    access plus available permission evidence; it does not guarantee future
    release or asset writes. Gitea's code-push permission metadata does not
    establish release-write or asset-write permission.
  • The CLI keeps RELEASEKIT_GITEA_TOKEN as its default token environment
    setting and preserves configured environment/file precedence. Selection,
    local credential-loading, and classified preflight configuration/access
    errors return status 2; unavailable preflight and cancellation during
    preflight/preparation return status 1. Later authorization failures follow
    delivery outcomes. An unresolved write returns status 3, including when
    cancellation prevents reconciliation; known delivery failures return 1.
  • Binary ci-deliver checks credentials before application dependency
    downloads and checks again during delivery. The automatic check now precedes
    full local artifact size and digest verification; those checks still finish
    before hosted writes.

  Correctness and efficiency

  • Dependency preparation now resolves the containing checkout root, including
    when called from a subdirectory or filesystem alias. ModuleDir is relative
    to that root, and empty selection prepares the root module. Standalone use
    retains the supplied directory as its base, including Go-only use when Git
    is unavailable. Damaged checkout metadata and operational discovery failures
    remain errors before dependency downloads.
  • Preparation overrides alternate module-file selection from inherited or
    persistent GOFLAGS, while retaining other effective Go settings. Downloads
    therefore use the selected module's ordinary metadata.
  • Candidate checking rejects a derived release tag that Git cannot create
    before running validation. CI delivery also validates the selected module's
    complete tag before dependency preparation.
  • Publication recovery treats a peeled-only tag observation as unresolved,
    retains the original push failure, and reports PublicationUnknown with CLI
    status 3. Complete tag observations retain their existing recovery behavior.
  • Cancellation and deadline expiration during build source inspection remain
    identifiable through errors.Is; partial results retain completed artifacts.
    Local artifact inspection errors also retain their underlying causes through
    delivery.
  • Gitea asset operations classify a missing or nonpositive service release ID
    as a malformed observation before making an asset request. Page-only release
    lookup retains its existing minimal response requirements.
  • Asset delivery uses linear pending-asset bookkeeping and sorts only missing
    assets once, reducing repeated work during uploads and reconciliation.

  Compatibility

  This pre-1.0 minor release changes the public destination type and requires
  explicit forge selection for delivery. Gitea is the supported backend.
  Preparation callers that previously used a checkout subdirectory as their
  implicit module selection must now select that module with ModuleDir.
  Ambient GOFLAGS no longer redirects preparation to an alternate module file.

  The module identifier remains go.maximumdirect.net/releasekit, and the Go
  consumer minimum remains 1.26.0. Receipt schemas and the separate source
  publication and hosted-delivery outcomes retain their existing definitions.

  Upgrade guidance

  Select v0.6.0 for library and CLI dependencies, then update integrations as
  follows:

  1. Replace releasekit.GiteaDestination with
     releasekit.DeliveryDestination and set
     Forge: releasekit.ForgeGitea in each API request.
  2. Add "forge": "gitea" to every profile used for deliver or
     ci-deliver, including profiles loaded from a tagged CI checkout. Keep the
     existing base_url, owner, repository, token environment, and token file
     settings.
  3. If handling preflight failures in Go, use errors.As to inspect
     *releasekit.DeliveryPreflightError and use errors.Is or errors.As on
     its unwrapped cause as needed.
  4. Continue to treat successful preflight as evidence of repository access,
     not a guarantee that a later write will be accepted. Source publication
     continues to use Git authentication and does not require hosted delivery
     credentials.
  5. For dependency preparation of a nested module, supply its repository-relative
     path through DependencyPreparationRequest.ModuleDir, even when
     RepositoryDir already points inside that module. Root-module consumers can
     keep ModuleDir empty.
  6. To adopt file-based credentials, store the token in an ignored local file
     and configure delivery.token_file. Optionally add that same
     repository-relative path to validation.forbidden_files. Credential loading
     and candidate file validation are independent selections; configuring the
     file alone does not enable the validator.

  See the delivery guide, configuration reference,
  CLI contract, and Gitea integration guide
  for current behavior.

  COPYRIGHT |
  LICENSE |
  ATTRIBUTION

  Downloads

  • Source Code (ZIP)
  • Source Code (TAR.GZ)
• v0.1.0 5e60fe3113

  Compare

  ReleaseKit v0.1.0 Stable

  eric released this 2026-10-07 02:50:32 +00:00 | 226 commits to main since this release

  ReleaseKit v0.1.0

  Summary

  ReleaseKit's initial release provides an opinionated Go library and executable
  for candidate validation, annotated source-tag publication, version injection,
  selected-target builds, and Gitea release delivery.

  The root releasekit facade owns release orchestration. The separate buildinfo
  facade supplies lightweight runtime version access. Both belong to one Go module
  with a Go 1.25.0 minimum language version.

  Capabilities

  • Run the standard offline Go test suite once, followed by optional
    product-specific checks and selected-target build verification.
  • Publish the exact annotated tag for a validated candidate already on
    authoritative main, with bounded recovery after failed or ambiguous pushes.
  • Cross-build selected Go targets with shared version injection, artifact names,
    digests, and a native version smoke check. Source-only projects select no
    binary targets.
  • Deliver committed release notes and declared assets to Gitea, preserving
    existing content and reporting partial, conflicting, and uncertain outcomes.
  • Use one managed build-and-deliver operation or supply retained prebuilt
    artifacts for retries and separate build/delivery environments.
  • Prepare tagged CI checkouts and dependencies through the shared ci-deliver
    command and maintained Woodpecker workflow.

  See the CLI contract,
  configuration reference,
  consumer delivery guide,
  and runtime version guide
  for supported behavior.

  Adoption and compatibility

  Consumers can select this initial baseline with:

  go get gitea.maximumdirect.net/eric/ReleaseKit@v0.1.0
  go install gitea.maximumdirect.net/eric/ReleaseKit/cmd/releasekit@v0.1.0
  

  Profiles declare product identity, additional checks, selected binaries and
  targets, and a Gitea destination. Applications obtain their embedded version
  through buildinfo.Version().

  For consumers experimenting with earlier development revisions, rename the
  ReleaseRequest.Validate callback to AdditionalChecks and remove repeated
  standard-suite commands from profile checks. DeliveryRequest.Build now
  accepts a *BuildSpec for managed builds; use Prebuilt for an existing
  BuildResult.

  Compatibility follows the release policy: before
  v1.0.0, minor releases may change documented contracts with migration guidance;
  patch releases preserve contracts within their minor line.

  ReleaseKit's deliverables are this immutable source tag and the hosted page
  containing this complete note. Consumer migration and live Woodpecker deployment
  remain adoption work tracked in the product roadmap.

  COPYRIGHT |
  LICENSE |
  ATTRIBUTION

  Downloads

  • Source Code (ZIP)
  • Source Code (TAR.GZ)