| Message ID | 20191119201940.70424-1-fabian@blaese.de |
|---|---|
| State | Accepted |
| Headers | show |
diff --git a/buildscript b/buildscript index 00f1874..0920b74 100755 --- a/buildscript +++ b/buildscript @@ -200,16 +200,18 @@ prebuild() { done < <(find "${builddir}/files" -name '*.tpl' -print0) #insert actual firware version informations into release file + variant=$(cat selected_variant) version=$(git describe --tags --dirty) if [ 0 -ne $? ]; then version=$(git log -1 --pretty=format:%h) fi - if [ -n "$(cat selected_variant)" ]; then - version="$(cat selected_variant)-$version" + if [ -n "$variant" ]; then + version="$variant-$version" fi { echo "FIRMWARE_VERSION=\"$version\"" + echo "VARIANT=\"$variant\"" echo "BUILD_DATE=\"build date: $(date)\"" echo "OPENWRT_CORE_REVISION=\"${OPENWRTREV}\"" echo "OPENWRT_FEEDS_PACKAGES_REVISION=\"${PACKAGEREV}\""
Reviewed-by: Christian Dresel <fff@chrisi01.de> On 19.11.19 21:19, Fabian Bläse wrote: > The variant is read multiple times from selected_variant file. > Therefore a variant variable is introduced. > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > buildscript | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/buildscript b/buildscript > index 00f1874..0920b74 100755 > --- a/buildscript > +++ b/buildscript > @@ -200,16 +200,18 @@ prebuild() { > done < <(find "${builddir}/files" -name '*.tpl' -print0) > > #insert actual firware version informations into release file > + variant=$(cat selected_variant) > version=$(git describe --tags --dirty) > if [ 0 -ne $? ]; then > version=$(git log -1 --pretty=format:%h) > fi > - if [ -n "$(cat selected_variant)" ]; then > - version="$(cat selected_variant)-$version" > + if [ -n "$variant" ]; then > + version="$variant-$version" > fi > > { > echo "FIRMWARE_VERSION=\"$version\"" > + echo "VARIANT=\"$variant\"" > echo "BUILD_DATE=\"build date: $(date)\"" > echo "OPENWRT_CORE_REVISION=\"${OPENWRTREV}\"" > echo "OPENWRT_FEEDS_PACKAGES_REVISION=\"${PACKAGEREV}\"" >
Hallo, > -----Original Message----- > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf > Of Fabian Bläse > Sent: Dienstag, 19. November 2019 21:20 > To: franken-dev@freifunk.net > Subject: [PATCH 1/4] buildscript: Add variant variable, store variant in > release-file Hier bitte klarmachen, dass /etc/firmware_release gemeint ist und nicht release.nfo. Ich hatte mich erst gewundert. Wenn das Einführen der Variable so wichtig ist, sollte es in einen eigenen Patch. Ich würde aber eher im Titel nur auf das Einführen in /etc/firmware_release hinweisen, und die Variable in der Commit Message vergraben. > > The variant is read multiple times from selected_variant file. > Therefore a variant variable is introduced. > > Signed-off-by: Fabian Bläse <fabian@blaese.de> > --- > buildscript | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/buildscript b/buildscript > index 00f1874..0920b74 100755 > --- a/buildscript > +++ b/buildscript > @@ -200,16 +200,18 @@ prebuild() { > done < <(find "${builddir}/files" -name '*.tpl' -print0) > > #insert actual firware version informations into release file > + variant=$(cat selected_variant) > version=$(git describe --tags --dirty) > if [ 0 -ne $? ]; then > version=$(git log -1 --pretty=format:%h) > fi > - if [ -n "$(cat selected_variant)" ]; then > - version="$(cat selected_variant)-$version" > + if [ -n "$variant" ]; then > + version="$variant-$version" > fi > > { > echo "FIRMWARE_VERSION=\"$version\"" Hier steckt die variant nach der Änderung schon mit drin... > + echo "VARIANT=\"$variant\"" ... also ist das eigentlich doppelt gemoppelt. Man kann die Variante also ohne Probleme zur Laufzeit auf dem Router mit ${FIRMWARE_VERSION%%-*} generieren, wo man sie braucht. So mache ich das in meiner Firmware mit den Varianten "adsc", "jubtl" usw. bisher. Ich würde auf das zusätzliche VARIANT verzichten. Grüße Adrian > echo "BUILD_DATE=\"build date: $(date)\"" > echo "OPENWRT_CORE_REVISION=\"${OPENWRTREV}\"" > echo "OPENWRT_FEEDS_PACKAGES_REVISION=\"${PACKAGEREV}\"" > -- > 2.24.0
On 20.11.19 00:21, mail@adrianschmutzler.de wrote: > Hallo, > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >> Of Fabian Bläse >> Sent: Dienstag, 19. November 2019 21:20 >> To: franken-dev@freifunk.net >> Subject: [PATCH 1/4] buildscript: Add variant variable, store variant in >> release-file > > Hier bitte klarmachen, dass /etc/firmware_release gemeint ist und nicht release.nfo. > > Ich hatte mich erst gewundert. > > Wenn das Einführen der Variable so wichtig ist, sollte es in einen eigenen Patch. Ich würde aber eher im Titel nur auf das Einführen in /etc/firmware_release hinweisen, und die Variable in der Commit Message vergraben. buildscript: add variant information to firmware_release This also introduces a variant variable in our buildscript, as it is necessery multiple times in the build process. So? Gruß Fabian
Hi, > buildscript: add variant information to firmware_release > This also introduces a variant variable in our buildscript, as > it is necessery multiple times in the build process. Gefällt mir besser. Wenn es noch hinpasst, würde ich sogar explizit "/etc/firmware_release" schreiben. Ich würde generell deutlich umfangreichere Commit Messages befürworten, aber das ist eine Grundsatzdiskussion und dafür ist dieser Patch sicher auch schlecht als Exempel geeignet. Sollte man aber vll. mal diskutieren, wenn man sich Gedanken über Commit-/Pushregeln macht. Grüße Adrian
Wow. Ich hätte nicht gedacht, dass es in meinem Umfeld noch Leute mit relevant höheren Ansprüchen an Commit Messages gibt, als mich. ;-D Dieser Patch tut ja jetzt nichts wahnsinnig komplexes, die Commit Message beschreibt das ja eigentlich auch vollständig. Man könnte jetzt noch dazu schreiben, wofür. Aber das ist dann ja eigentlich der nächste Patch. Generell stelle ich fest, dass unsere Commit Messages eh schon recht umfangreicher sind, teilweise viel umfangreicher als in anderen Projekte, die ich kenne. Ich bin aber auf jeden Fall auch für Messages, die das Problem und die Lösung ausreichend beschreiben. Gruß Fabian On 20.11.19 17:31, Adrian Schmutzler wrote: > Hi, > >> buildscript: add variant information to firmware_release >> This also introduces a variant variable in our buildscript, as >> it is necessery multiple times in the build process. > > Gefällt mir besser. > > Wenn es noch hinpasst, würde ich sogar explizit "/etc/firmware_release" schreiben. > > Ich würde generell deutlich umfangreichere Commit Messages befürworten, aber das ist eine Grundsatzdiskussion und dafür ist dieser Patch sicher auch schlecht als Exempel geeignet. > > Sollte man aber vll. mal diskutieren, wenn man sich Gedanken über Commit-/Pushregeln macht. > > Grüße > > Adrian >
> Generell stelle ich fest, dass unsere Commit Messages eh schon recht umfangreicher sind, teilweise viel umfangreicher als in anderen Projekte, die ich kenne. > Ich bin aber auf jeden Fall auch für Messages, die das Problem und die Lösung ausreichend beschreiben. Ich hatte halt schon oft das Problem, dass ich irgendwas in alten Commits recherchiert habe, und mir eine ordentlich Commit Message ne Stunde Arbeit erspart hätte, um es selbst rauszufinden. Ich nerve da auch die Submitter bei OpenWrt inzwischen sehr nachhaltig, dass möglichst viel Information in die Commit Message rein soll. Und gerade mit so wenigen Entwicklern wie bei uns ist das umso wichtiger, da noch weniger da sind, die einen bestimmten Teil im Detail verstehen, und die man fragen kann. Grüße Adrian
Full Ack. On 20.11.19 19:05, Adrian Schmutzler wrote: >> Generell stelle ich fest, dass unsere Commit Messages eh schon recht umfangreicher sind, teilweise viel umfangreicher als in anderen Projekte, die ich kenne. >> Ich bin aber auf jeden Fall auch für Messages, die das Problem und die Lösung ausreichend beschreiben. > > Ich hatte halt schon oft das Problem, dass ich irgendwas in alten Commits recherchiert habe, und mir eine ordentlich Commit Message ne Stunde Arbeit erspart hätte, um es selbst rauszufinden. > > Ich nerve da auch die Submitter bei OpenWrt inzwischen sehr nachhaltig, dass möglichst viel Information in die Commit Message rein soll. > > Und gerade mit so wenigen Entwicklern wie bei uns ist das umso wichtiger, da noch weniger da sind, die einen bestimmten Teil im Detail verstehen, und die man fragen kann. > > Grüße > > Adrian >
Mit gewünschter Änderung der Commit Message applied.
The variant is read multiple times from selected_variant file. Therefore a variant variable is introduced. Signed-off-by: Fabian Bläse <fabian@blaese.de> --- buildscript | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)