Ideen gesucht. Repository der eigenen Community strukturieren, bauen erleichtern

Hallo,
ich möchte unser git Repository in dem die Konfiguration für unsere Firmware liegt etwas verbessern.
Meine Ziele sind:

  • Jeder soll einfach unsere veröffentlichte Firmware exakt nachbauen können
  • Ein Buildserver soll nightly versionen erstellen können
  • Ich möchte Strickt nach dem Schema Entwicklung → Test → Release vorgehen und dabei zwischen den Phasen keinen Code händisch ändern müssen.

Für die ersten beiden Punkte wäre es wichtig zu hinterlegen auf welcher Gluon Version/Commit/Branch das ganze basiert. hat dazu jemand eine Idee? Bisher muss man das manuell angeben.

Für den 3. Punkt müsste man vermutlich den Namen der Branch irgendwie automatisch beim bauen übergeben.

1 Like

Wir bauen ja aus einem modifizierten Gluon (weshalb Releasewechsel leider noch immer schmerzhaft sind), da löse ich das so:

MYBUILDNBR="`cat buildnumber.txt`"
MYBUILDNBR="`expr ${MYBUILDNBR} + 1`"
echo "${MYBUILDNBR}" >buildnumber.txt
[...]
GLUONPKGCOMMIT="`(cd gluon-packages-ffgt-v2015.1/; git rev-parse HEAD)`"
FFGTPKGCOMMIT="`(cd ffgt_packages-v2015.1/; git rev-parse HEAD)`"
FFGTSITECOMMIT="`(cd site-ffgt-v2015.1/; git rev-parse HEAD)`"
GLUONBASECOMMIT="`(cd gluon-2015.1-ffgt/; git rev-parse HEAD)`"
RELEASE="`cat baserelease.txt`${MYBUILDNBR}"
/bin/rm -f /tmp/build-2015.1-release.txt
rsync -av --progress site-ffgt-v2015.1/ gluon-2015.1-ffgt/site/
sed -i -e "s/^DEFAULT_GLUON_RELEASE :=.*$/DEFAULT_GLUON_RELEASE := ${RELEASE}/" gluon-2015.1-ffgt/site/site.mk
sed -i -e "s/^PACKAGES_FFGT_PACKAGES_COMMIT=.*$/PACKAGES_FFGT_PACKAGES_COMMIT=${FFGTPKGCOMMIT}/" gluon-2015.1-ffgt/site/modules
sed -i -e "s/^PACKAGES_GLUON_COMMIT=.*$/PACKAGES_GLUON_COMMIT=${GLUONPKGCOMMIT}/" gluon-2015.1-ffgt/modules
sed -i -e "s%^PACKAGES_GLUON_REPO=.*$%PACKAGES_GLUON_REPO=https://github.com/ffgtso/gluon-packages-ffgt-v2015.1.git%" gluon-2015.1-ffgt/modules
[...]
touch images/factory/ffgt-firmware-buildinfo-${RELEASE}
echo "Release: ${RELEASE}" >>images/factory/ffgt-firmware-buildinfo-${RELEASE}
echo "PACKAGES_FFGT_PACKAGES_COMMIT=${FFGTPKGCOMMIT}" >>images/factory/ffgt-firmware-buildinfo-${RELEASE}
echo "PACKAGES_GLUON_COMMIT=${GLUONPKGCOMMIT}" >>images/factory/ffgt-firmware-buildinfo-${RELEASE}
echo "GLUON_BASE_COMMIT=${GLUONBASECOMMIT}" >>images/factory/ffgt-firmware-buildinfo-${RELEASE}
echo "Buildslave: ${NODE_NAME}" >>images/factory/ffgt-firmware-buildinfo-${RELEASE}
echo "Buildjob: ${JOB_URL}" >>images/factory/ffgt-firmware-buildinfo-${RELEASE}

Damit liegen eigentlich alle Daten vor, exakt eine Version nachzubauen bzw. den Build nachzuvollziehen im (privaten) Jenkins. (Probiert habe ich einen Nachbau aber auch noch nicht ;))

Initialer Build (zweistufig: ein »PoC«-Lauf baut single-threaded nur 841v9 bis v11 und x86-kvm, um Fehler zu finden; manuell zu startender 2. Job baut dann mit -j8 alles) …

make manifest GLUON_BRANCH=rawhide
make manifest GLUON_BRANCH=experimental
make manifest GLUON_BRANCH=testing
make manifest GLUON_BRANCH=stable
contrib/sign.sh ~/secret-build images/sysupgrade/rawhide.manifest
contrib/sign.sh ~/secret-build images/sysupgrade/experimental.manifest
contrib/sign.sh ~/secret-build images/sysupgrade/testing.manifest
contrib/sign.sh ~/secret-build images/sysupgrade/stable.manifest
mv images/sysupgrade/experimental.manifest images/sysupgrade/experimental.manifest-${RELEASE}
mv images/sysupgrade/testing.manifest images/sysupgrade/testing.manifest-${RELEASE}
mv images/sysupgrade/stable.manifest images/sysupgrade/stable.manifest-${RELEASE}
chmod g+w images/factory images/sysupgrade
rsync -av --omit-dir-times --progress images/* /nfs/firmware/rawhide/

Die Jobs, ein (effektiv: das zuletzt gebaute) Image über rawhide (frisch gebacken, blutig, nicht abgehangen oder auch nur eines Blickes gewürdigt) nach experimental nach testing nach stable zu hieven, sind dann relativ einfach:

  #
  # << make sure the manifest is signed properly! >>
  #
  mv images/sysupgrade/testing.manifest-${RELEASE} images/sysupgrade/testing.manifest
  rsync -av --omit-dir-times --progress images/* /nfs/firmware/testing/

Was so nicht geht: neuen Build haben und älteren Build promoten. Kann man aus dem rawhide-Verzeichnis per ${RELEASE}-Pattern aber raussyncen; die Anzahl der Commiter ist aber hier so überschaubar, daß der Fall selten auftritt :wink:

HTH.