public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: "Maxim Yu. Osipov" <mosipov@ilbers.de>
Cc: <isar-users@googlegroups.com>
Subject: Re: [PATCH] meta/image: leave BUILD_ID and VARIANT in /etc/os-release
Date: Fri, 29 Jun 2018 13:46:20 +0200	[thread overview]
Message-ID: <20180629134620.1a0a1832@md1pvb1c.ad001.siemens.net> (raw)
In-Reply-To: <ccae6237-262a-fe75-18e4-449781866537@ilbers.de>

Am Fri, 29 Jun 2018 12:04:25 +0200
schrieb "Maxim Yu. Osipov" <mosipov@ilbers.de>:

> Hi Henning,
> 
> On 06/28/2018 05:09 PM, Henning Schild wrote:
> > Am Thu, 28 Jun 2018 17:05:21 +0200
> > schrieb Henning Schild <henning.schild@siemens.com>:
> >   
> >> This commit adds support for leaving a mark in the resulting image.
> >> That should allow you to tell what code you used to create it. By
> >> default "git describe" will be used on Isar itself to come up with
> >> a BUILD_ID. And the DESCRIPTION of the image will become the
> >> VARIANT.
> >>
> >> see
> >> https://www.freedesktop.org/software/systemd/man/os-release.html
> >>
> >> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> >> ---
> >>   meta-isar/recipes-core/images/isar-image-base.bb |  2 ++
> >>   meta/classes/image.bbclass                       | 27
> >> ++++++++++++++++++++++++
> >> meta/classes/isar-bootstrap-helper.bbclass       | 26
> >> +++++++++++++++++++++++ 3 files changed, 55 insertions(+)
> >>
> >> diff --git a/meta-isar/recipes-core/images/isar-image-base.bb
> >> b/meta-isar/recipes-core/images/isar-image-base.bb index
> >> 6cdc6b2..c72bfdb 100644 ---
> >> a/meta-isar/recipes-core/images/isar-image-base.bb +++
> >> b/meta-isar/recipes-core/images/isar-image-base.bb @@ -24,6 +24,8
> >> @@ IMAGE_TRANSIENT_PACKAGES += "isar-cfg-localepurge"
> >>   WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
> >>   
> >> +ISAR_GIT_RELEASE_PATH ?= "${LAYERDIR_isar}"
> >> +
> >>   do_rootfs[root_cleandirs] = "${IMAGE_ROOTFS} \
> >>                                ${IMAGE_ROOTFS}/isar-apt"
> >>   
> >> diff --git a/meta/classes/image.bbclass
> >> b/meta/classes/image.bbclass index 3bdcb2f..00040e5 100644
> >> --- a/meta/classes/image.bbclass
> >> +++ b/meta/classes/image.bbclass
> >> @@ -34,6 +34,25 @@ def get_rootfs_size(d):
> >>   
> >>       return base_size + rootfs_extra * 1024
> >>   
> >> +# we assume that one git commit can describe the whole image, so
> >> you should be +# using submodules, kas, or something like that
> >> +# set ISAR_GIT_RELEASE_PATH to that one "most significant" layer
> >> +# when not using git, override do_mark_rootfs
> >> +def get_build_id(d):
> >> +    import subprocess
> >> +    if (len(d.getVar("BBLAYERS", True).strip().split(' ')) != 2
> >> and
> >> +        (d.getVar("ISAR_GIT_RELEASE_PATH", True) ==
> >> +         d.getVar("LAYERDIR_isar", True))):
> >> +        bb.warn('You are using external layers that will not be
> >> considered' +
> >> +                ' in the build_id. Considder setting
> >> ISAR_GIT_RELEASE_PATH.')
> >> +    base = ["git", "-C", d.getVar("ISAR_GIT_RELEASE_PATH", True)]
> >> +    if (0 == subprocess.call(base + ["rev-parse"])):
> >> +        v = subprocess.check_output(base +
> >> +                                    ["describe", "--long",
> >> "--dirty",
> >> +                                     "--always"],  
> > 
> > Here i am not sure what arguments to use. That also depends on the
> > tagging of the project. We might want to make this configurable,
> > since the "most significant" layer might use different tagging.
> > Opinions?  
> 
> In my opinion 'git describe --dirty --match "v[0-9].[0-9]*" would be
> enough.
> 
> It would be nice to add document describing versioning 
> docs/VERSIONING.md. Something like that:
> 
>  >>>  
> ISAR Versioning
> 
> ISAR uses for release versioning unsigned, annotated tag
> in format "v[0-9].[0-9]*".
> 
> The following procedure has to be followed for release versioning:
> 
> 1) Update CHANGELOG.md in ISAR root directory.
> 
> 2) Before creation of final release, prepare release candidate(s)
> with the help of command 'git tag -a <release_candidate_tagname>',
> where <release_candidate_tagname> has the format
> "v[0-9].[0-9]-rc[0-9]"
> 
> 3) When final release is ready create annotated tag
> with the help of command 'git tag -a <release_tagname>', where
> <release_tagname> has the format "v[0-9].[0-9]"
> 
> BUILD_ID field in /etc/os-release keeps ISAR repository version
> derived with the help of command 'git describe --dirty --match 
> "v[0-9].[0-9]*'.
> 
> This command finds the most recent annotated tag that is reachable
> from a commit.
> If the tag points to the commit, then only the tag is shown.
> Otherwise, it suffixes the tag name with the number of additional
> commits on top of the tagged object and the abbreviated object name
> of the most recent commit. If the working tree is modified '-dirty'
> will be appended to the end of the version string.
> 
> For example, BUILD_ID may have the values like
> - "v3.0-rc2" for 3.0 release candidate 2
> - "v3.0" for released 3.0 version
> - "v3.0-112-g118cd4b" for developer's version,
> meaning that 112 commits exist since recent release and the most
> recent commit has abbreviated name 118cd4b.
> - "v3.0-112-g118cd4b-dirty" for developer's version,
> meaning that 112 commits exist since recent release, the most
> recent commit has abbreviated name 118cd4b and the working tree
> is modified.
>  >>>  
> 
> Is it OK?

Thanks for citing half of the manpage ;). I think you can do whatever
you want. The point is that get_build_id should be generic enough to
also work for repos calling their tags completely differently, or not
using tags at all.
Think of a private layer-repo that happens to use Isar but has another
versioning policy. The BUILD_ID in the image should be the one of that
layer, set by ISAR_GIT_RELEASE_PATH.
People that do not use git at all override do_mark_rootfs, but for the
ones using git it would be nice if they would not have to.

Henning

> 
> > 
> > In that regard i realized that the tags on Isar are not consistent.
> > v0.3 seems to be the last annotated one.  
> 
> Thank you for pointing this out - after applying your patch we will 
> start to follow well defined versioning/release policy.
> 
> Kind regards,
> Maxim.
> 
> > 
> > Henning
> >   
> >> universal_newlines=True)
> >> +        return v.rstrip()
> >> +    return ""
> >> +
> >>   python set_image_size () {
> >>       rootfs_size = get_rootfs_size(d)
> >>       d.setVar('ROOTFS_SIZE', str(rootfs_size))
> >> @@ -56,6 +75,14 @@ do_rootfs() {
> >>   addtask rootfs before do_build after do_unpack
> >>   do_rootfs[deptask] = "do_deploy_deb"
> >>   
> >> +do_mark_rootfs() {
> >> +    update_etc_os_release \
> >> +        --build-id "${@get_build_id(d)}" --variant
> >> "${DESCRIPTION}" \
> >> +        "${IMAGE_ROOTFS}"
> >> +}
> >> +
> >> +addtask mark_rootfs before do_copy_boot_files after do_rootfs
> >> +
> >>   do_copy_boot_files() {
> >>       KERNEL_IMAGE=${@get_image_name(d, 'vmlinuz')[1]}
> >>       if [ -n "${KERNEL_IMAGE}" ]; then
> >> diff --git a/meta/classes/isar-bootstrap-helper.bbclass
> >> b/meta/classes/isar-bootstrap-helper.bbclass index 3c10fc7..f375853
> >> 100644 --- a/meta/classes/isar-bootstrap-helper.bbclass
> >> +++ b/meta/classes/isar-bootstrap-helper.bbclass
> >> @@ -14,6 +14,32 @@ def reverse_bb_array(d, varname):
> >>       array = reversed(array.split())
> >>       return " ".join(i for i in array)
> >>   
> >> +update_etc_os_release() {
> >> +    OS_RELEASE_BUILD_ID=""
> >> +    OS_RELEASE_VARIANT=""
> >> +    while true; do
> >> +        case "$1" in
> >> +	--build-id) OS_RELEASE_BUILD_ID=$2; shift ;;
> >> +	--variant) OS_RELEASE_VARIANT=$2; shift ;;
> >> +        -*) bbfatal "$0: invalid option specified: $1" ;;
> >> +        *) break ;;
> >> +        esac
> >> +        shift
> >> +    done
> >> +    ROOTFSDIR="$1"
> >> +
> >> +    if [ -n "${OS_RELEASE_BUILD_ID}" ]; then
> >> +        sudo sed -i '/^BUILD_ID=.*/d' ${ROOTFSDIR}/etc/os-release
> >> +        echo "BUILD_ID=\"${OS_RELEASE_BUILD_ID}\"" | \
> >> +            sudo tee -a ${ROOTFSDIR}/etc/os-release
> >> +    fi
> >> +    if [ -n "${OS_RELEASE_VARIANT}" ]; then
> >> +        sudo sed -i '/^VARIANT=.*/d' ${ROOTFSDIR}/etc/os-release
> >> +        echo "VARIANT=\"${OS_RELEASE_VARIANT}\"" | \
> >> +            sudo tee -a ${ROOTFSDIR}/etc/os-release
> >> +    fi
> >> +}
> >> +
> >>   setup_root_file_system() {
> >>       CLEAN=""
> >>       FSTAB=""  
> >   
> 
> 


  reply	other threads:[~2018-06-29 11:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 15:05 Henning Schild
2018-06-28 15:09 ` Henning Schild
2018-06-29 10:04   ` Maxim Yu. Osipov
2018-06-29 11:46     ` Henning Schild [this message]
2018-07-02  9:15 ` Maxim Yu. Osipov
2018-07-02 18:19   ` [PATCH] meta/image: allow customization of git command we use fo BUILD_ID Henning Schild
2018-07-02 18:30     ` Henning Schild
2018-07-03  7:50     ` Henning Schild
2018-07-03  7:39   ` [PATCH] meta/image: allow customization of " Henning Schild
2018-07-03  7:49     ` Henning Schild
2018-07-20 12:38     ` Henning Schild
2018-07-20 13:17       ` Maxim Yu. Osipov
2018-07-20 13:44         ` Henning Schild
2018-07-23  6:38     ` Jan Kiszka
2018-07-23  6:40       ` Jan Kiszka
2018-07-23  7:34         ` Henning Schild
2018-07-25 10:33     ` Maxim Yu. Osipov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180629134620.1a0a1832@md1pvb1c.ad001.siemens.net \
    --to=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=mosipov@ilbers.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox