Repository navigation
docs+ci: document local builds, remove the dead build script, pin actions - #128
Open
Bjordis Collaku (bjordiscollaku) wants to merge 4 commits into
Open
Bjordis Collaku (bjordiscollaku) wants to merge 4 commits into
Bjordis Collaku (bjordiscollaku) wants to merge 4 commits into
Conversation
Bjordis Collaku (bjordiscollaku)
changed the title
Building this kernel outside CI was undocumented. INTEGRATION.md's "Building" section pointed at PIPELINE.md, which covers dispatching the workflow rather than building on a developer's own machine. Add docs/LOCAL-BUILD.md, following build-kernel.yml. Each step was run through to a successful build-dep on resolute-qcom-devel before being written down, which is what turned up the parts that are not guessable: the published builder image is private, so the image is built locally and tagged with the same name rather than pulled; docker_deb_build.py refuses to run when its checkout is behind its remote; debian/rules clean has to precede build-dep because it generates the debian/control that build-dep reads; and output lands beside the source tree rather than inside it. Also records what a build otherwise fails on: the flavour names are qcom and qcom-rt with no generic, binary-indep has to accompany a flavour because the per-flavour packages depend on what it builds, and the Qualcomm sources file is needed for the DKMS module sources, which are not in the Ubuntu archive. Only measured figures are quoted. Build duration and peak disk are left out rather than carried over from the script this replaces, which stated both without this build path ever having produced them. Two fixes to existing text while in the same files. INTEGRATION.md linked to PIPELINE.md#manual-build-triggers, and no such heading exists; it is "Running it". And the README opened by stating this repository is not accepting contributions, which contradicts INTEGRATION.md describing Qualcomm contributions landing on resolute-qcom-devel through pull requests, as they do; CONTRIBUTING.md and SECURITY.md still carry their own statements and the documentation table still links to both. Documentation only. Signed-off-by: Bjordis Collaku <bcollaku@qti.qualcomm.com>
build-kernel-deb.sh has no callers: nothing on main references it, and neither does the CI on resolute-qcom or resolute-qcom-devel. It predates the containerised build. Left in place it reads as the supported way to build locally, and it would fail. It installs build dependencies before running debian/rules clean, so it resolves against a debian/control that has not been generated yet. It does not add the Qualcomm sources, so the DKMS module sources cannot be found. It defaults to flavour "generic", which this kernel does not define. It omits binary-indep, so linux-headers and linux-qcom-* are never produced. And it builds on the host rather than in the suite-matched container. docs/LOCAL-BUILD.md documents the supported path. Signed-off-by: Bjordis Collaku <bcollaku@qti.qualcomm.com>
Every action outside premerge-distro-validation.yml was referenced by a moving tag, so a build ran whatever the tag pointed at that day. premerge-distro-validation.yml was already pinned and is the pattern the rest now follow. Each reference is pinned to the commit its tag resolves to today, so behaviour is unchanged by construction: actions/checkout@v6 -> v6.1.0 actions/cache/restore@v4, cache/save@v4 -> v4.3.0 actions/stale@v10 -> v10.4.0 upload-private-artifact-action@aws-v4 -> aws-v4 The version each hash came from is kept in a trailing comment, including on the five already-pinned checkout references, so a reader can tell what is pinned without resolving it. Two things left alone. premerge-distro-validation.yml stays on checkout v4.4.0 while the others are on v6.1.0: unifying them is a version bump rather than a pin. Likewise upload-private-artifact-action has an aws-v5 tag, but this pins the aws-v4 the workflow already used. Signed-off-by: Bjordis Collaku <bcollaku@qti.qualcomm.com>
Bjordis Collaku (bjordiscollaku)
force-pushed
the
ci/phase1-docs-and-pinning
branch
from
October 8, 2026 17:28
900bfb6 to
24f98de
Compare
Bjordis Collaku (bjordiscollaku)
marked this pull request as ready for review
October 8, 2026 17:34
CI appends +qcom<N>.<sha> to builds that have commits past a Canonical tag, through apply-local-version-suffix.sh. The local build guide does not run that step, so a local build of resolute-qcom-devel produces packages carrying the exact version of the Canonical upload it is based on. Say so, and describe the guide as using the same container and steps as build-kernel.yml rather than as building the same way, since the version is the one thing that differs. Signed-off-by: Bjordis Collaku <bcollaku@qti.qualcomm.com>
Bjordis Collaku (bjordiscollaku)
force-pushed
the
ci/phase1-docs-and-pinning
branch
from
October 9, 2026 18:35
3f15143 to
a3d3692
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #130, closes #131.
First of a stacked series. Documentation and pinning only, with no change to how any build runs.
docs/LOCAL-BUILD.md. The steps were run through to a successfulbuild-deponresolute-qcom-develbefore being written down, which is what surfaced the parts that are not guessable: the published builder image is private, so it is built locally and tagged with the same name rather than pulled;docker_deb_build.pyrefuses to run when its checkout is behind its remote;debian/rules cleanhas to precedebuild-depbecause it generates thedebian/controlthatbuild-depreads; and output lands beside the source tree rather than inside it.Only measured figures are quoted. Build duration and peak disk are left out rather than carried over from the script this replaces, which stated both without this path having produced them.
Dead script.
scripts/build-kernel-deb.shhas no callers on any branch and would fail five ways, detailed in #130.Action pinning. Each reference is pinned to the commit its tag resolves to today, so behaviour is unchanged by construction, with the version kept in a trailing comment.
Also fixes a dead anchor in
INTEGRATION.md:PIPELINE.md#manual-build-triggersdoes not exist, the heading is "Running it".Draft while the rest of the series is prepared.