Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Feed release lane takes 2.6–4.3 h/job: per-job 260 MB SDK tarball fetch; move iteration to the deterministic non-SDK path + cache/pin the SDK lane

Open
  • Is something wrong?
#826 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
22/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, go, shell
Domain
build-system, ci-cd

Research direction

Start with the tag-triggered workflow release-publish.yml and the SDK download step, then packaging/local-build-ipk.sh and packaging/build-env.sh for the non-SDK build path. Done means the release lane caches or pins the SDK tarball, and a non-SDK build passes a parity check against the SDK build's file set and binary hashes. The issue is design-heavy and has no maintainer decision yet, so confirm scope before writing code.

Written by the indexing model from the issue text.

Description

area: build-infra

Filed here rather than FreedomTechFeed/packages (issues disabled there) because the deterministic-build machinery this proposes lives in this repo (packaging/), and the feed's release lane is what publishes every preN we test.

Summary

The feed's tag-triggered release lane (release-publish.yml) intermittently takes hours per job. The pre26-era run 37839847702 (2026-10-08): 262 min wall, all 16 per-arch jobs between 2.3 h and 4.3 h. Not a compile problem — it is the per-job download of the ~260 MB SDK tarball from the OpenWrt mirror, which that night moved at ~20 KB/s from GitHub-hosted (Azure) runners.

Evidence

1. Log decomposition of the slowest job (Build x86_64 (openwrt-24.10), 15,613 s):

Phase Time
job setup, checkout, portal bundle ~10 min
sha256sums fetch + GPG verify 20:40:53
SDK tarball (260 MB) download completes 00:19:22 — 3 h 38 min later (~20 KB/s), zero progress output
dependency-closure compile (unbound, iptables, gnutls, gettext, …) ~25 min
tollgate-wrt itself (both Go binaries) ~1 min

2. Intermittent, not constant — release-lane wall times: Oct 4: 46 m · Oct 6: 53 m · 58 m · Oct 7: 45 m · Oct 8: 262 m · Oct 9: 32 m.

3. The mirror is not generally slow — same URL measured 2026-10-09: 5.6 MB/s from the lab host, 6.2 MB/s via downloads.openwrt.org, 1.1 MB/s from a workstation.

4. Mechanism (upstream by design) — gh-action-sdk ships snapshot SDK containers without the SDK ("to save bandwidth"); every job fetches the tarball at run time. Our ipk lane rides 24.10-SNAPSHOT. The apk lane already moved to released-branch SDKs for this class of problem (feed PR #54).

Rate limiting?

Unprovable from runner logs; the evidence says not targeted at us: GitHub runners are anonymous to the mirror, our direct pulls the same day were 100–300× faster, and good days are fine. Plausible: transient Azure↔mirror peering congestion, or per-IP fair-use shaping hitting GitHub's shared runner egress IPs (polluted by every tenant's OpenWrt CI). Upstream already manages this bandwidth deliberately; heavy CI consumers are expected to cache or use released images. The mitigations make the question moot.

Plan (cheapest first)

  1. actions/cache the SDK tarball keyed by its sha256 digest (~4 s restore at ~70 MB/s vs up to 3.6 h) — for any lane that must stay on snapshots.
  2. Pin the feed's ipk lane to a released 24.10.x SDK (bundled-SDK image → no download at all, immutable cache scope, no sha256 race) — same discipline the feed's apk lane already enforces (Gates H/I).
  3. PR/iteration signal from the deterministic non-SDK path — packaging/local-build-ipk.sh already produces release-grade deterministic .ipk without any SDK (committed packaging/tollgate-wrt_v0.6.0-rc1-local_*.ipk prove it). Measured 2026-10-09: ~5–7 min/arch cold, ~1–4 min warm (service 4–6 m cold, CLI 47 s, second arch ~4 m) vs hours for the SDK lane — and zero OpenWrt-mirror dependency. Gap: .apk assembly without SDK (apk-tools-static mkpkg; ipk assembler exists). Gate with a parity check vs the SDK build (file set + binary hashes; binaries reproducible via -trimpath + SOURCE_DATE_EPOCH per packaging/build-env.sh), extending the feed's pkg-tarball-parity culture.
  4. Optionally pre-bake org SDK images on ghcr.

1+2 take a bad-day release cut from 4.3 h → ~35 min; 3 removes the mirror from iteration entirely.

Methodology: conwrt-bench sessions/2026-10-09-vlab-installer-e2e-rounds.md (release-club QEMU lane sessions).

Dominant language
Go
Stars
12
Forks
14
Avg merge
1d 6h
Merged PRs (30d)
234

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenTollGate/tollgate-module-basic-go

All issues in OpenTollGate/tollgate-module-basic-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.