Skip to content

ci: community publishes to armbian/community with its own version series - #38

Open
igorpecovnik wants to merge 4 commits into
mainfrom
community-release-to-own-repo
Open

ci: community publishes to armbian/community with its own version series#38
igorpecovnik wants to merge 4 commits into
mainfrom
community-release-to-own-repo

Conversation

@igorpecovnik

@igorpecovnik igorpecovnik commented Jul 30, 2026

Copy link
Copy Markdown
Member

What

Community images publish to armbian/community (not the shared armbian/ci), and nightly + community share one monotonic -trunk.N counter.

Release targeting

New release_target_repository input (default → github.repository, so nightly/others unchanged), threaded through version lookup, release creation, mark-latest, CDN mirror pull, image upload, and torrent webseed. Community sets it to armbian/community. OCI artifact cache is untouched — only the GitHub image releases move.

Shared trunk counter

The -trunk.N number is monotonic across armbian/ci (nightly = the leader) and armbian/community (peer). Both callers list the other in trunk_peer_repositories, so either track sees the whole counter.

  • Nightly (leader): always cuts the next number — max(N across ci+community) + 1. A bump always lands above community.
  • Community (non-leader): reuses the leader's current number when the leader is ahead (so its tags line up with the current nightly), otherwise bumps to max+1 — so a second community run with no nightly in between still advances.

Selection is sort -V (correct across base version + N, and robust to bulk-imported equal-timestamp releases). Replaces the earlier naive "always reuse" flag.

Behaviour table

state (ci / community) nightly runs community runs
7 / 7 → 8 → 8 (level, bump)
8 / 7 → 9 reuse 8 (leader ahead)
8 / 8 → 9 → 9 (level, bump)

Operational prerequisites

  1. ACCESS_TOKEN must have write access to armbian/community (release + asset upload), else the community build fails at "Create release".
  2. The counter floor is whatever exists in either repo. armbian/community was cleaned to line up with nightly's series (currently both at trunk.7).

Companion to armbian/armbian.github.io#370 (download index reads community images from the community repo).

Community images were reading/bumping -trunk.N from the shared release repo
(github.repository, = armbian/ci) and publishing there, so they reused
nightly's version instead of getting their own, and the images landed next
to nightly's.

Add a release_target_repository input to complete-artifact-matrix.yml /
build-images-chunk.yml (default empty -> github.repository, so nightly and
every other track are unchanged) and route the version lookup, release
creation, mark-latest, CDN mirror pull_repository, image upload and torrent
GitHub webseed through it. build-community.yml sets it to armbian/community,
so community now reads/bumps its own -trunk.N there and publishes its images
and releases into armbian/community.

Operational notes:
- The release token (ACCESS_TOKEN) must have write access to armbian/community.
- armbian/community needs a seed -trunk.N release; the first community run
  after this should pass versionOverride to start the series (same as any
  nightly track), otherwise version_prep errors with "no existing
  <base>-trunk.N release".

Signed-off-by: Igor Pecovnik <igor@armbian.com>
The nightly-path version bump sorted trunk releases by createdAt and took the
last. armbian/community's releases were bulk-imported with one shared
timestamp, so the sort was arbitrary: it picked 26.8.0-trunk.170 and bumped to
171 — a tag that already exists — while the real max was trunk.417. A --limit
100 could also truncate a large series below its max.

Sort by version instead ([major,minor,patch] then N) and raise --limit, so the
next version is always max(N)+1 (e.g. community 417 -> 418) regardless of
import timestamps. No effect on repos with normal per-release timestamps
(armbian/ci), where highest-N and newest-createdAt coincide.

Signed-off-by: Igor Pecovnik <igor@armbian.com>
Refine the community targeting: the -trunk.N series lives only in armbian/ci
and only nightly bumps it. Community reads that same series from armbian/ci
and reuses the last trunk number as-is (reuse_latest_trunk=yes), so its images
carry the current nightly version -- just published to armbian/community
instead of armbian/ci.

Version SOURCE is github.repository (armbian/ci) for every track again; only
the release TARGET differs per track (release_target_repository). Drops the
earlier "community bumps its own series out of armbian/community" behaviour,
which reused stale bulk-imported tags.

Signed-off-by: Igor Pecovnik <igor@armbian.com>
Replace community's naive "always reuse" with a monotonic -trunk.N counter
shared by armbian/ci (nightly, the leader) and armbian/community (peer):

- LEADER (nightly) always cuts the next number: max(N across ci+community)+1,
  so a nightly bump always lands above community.
- A non-leader target (community) reuses the leader's current number when the
  leader is ahead of it (community tracks the fresh nightly version); if it is
  already level with the leader, it cuts the next number instead. So a second
  community run with no nightly in between still bumps.

Both callers list armbian/community in trunk_peer_repositories so either track
sees the whole counter. Replaces the reuse_latest_trunk flag. Version compare
is sort -V (handles base + N, and repos with bulk-imported equal timestamps).

Signed-off-by: Igor Pecovnik <igor@armbian.com>
@igorpecovnik
igorpecovnik force-pushed the community-release-to-own-repo branch from 12aafb4 to 0996721 Compare August 2, 2026 04:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant