public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Moessbauer, Felix" <felix.moessbauer@siemens.com>
To: Anton Mikanovich <amikan@ilbers.de>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"henning.schild@siemens.com" <henning.schild@siemens.com>,
	"Schmidt, Adriaan" <adriaan.schmidt@siemens.com>
Subject: RE: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD
Date: Wed, 17 Nov 2021 15:57:53 +0000	[thread overview]
Message-ID: <AM9PR10MB4869539EA113154BACEFB107899A9@AM9PR10MB4869.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <4bf7b75d-f431-9a07-96f0-a1168af073d3@ilbers.de>

> -----Original Message-----
> From: Anton Mikanovich <amikan@ilbers.de>
> Sent: Wednesday, November 17, 2021 2:06 PM
> To: Moessbauer, Felix (T RDA IOT SES-DE) <felix.moessbauer@siemens.com>
> Cc: isar-users@googlegroups.com
> Subject: Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD
> 
> 17.11.2021 13:45, Moessbauer, Felix wrote:
> > Hi Anton,
> >
> > Unfortunately I cannot reproduce this, but this is very likely related to a not
> idempotent ISAR_RELEASE_CMD.
> > As stated in the API changelog, the ISAR_RELEASE_CMD shall be idempotent
> (and technically must be for MC targets).
> > By that, no things like timestamps must be included.
> >
> > If you point me to the location where the ISAR_RELEASE_CMD is set for CI
> builds, I can have a look.
> > Another issue could be that changes to the git happen during build (e.g. adding
> a tag, making the repo dirty, etc...).
> > In that case (starting with a clean build, ending up with a dirty one), the CI
> generated files have to be added to the .gitignore.
> >
> > In Yocto there is a lengthy discussion about the idempotence sanity check [1]
> and why recipes have to be written in this way.
> >
> > Best regards,
> > Felix
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.openembedded.org%2Fpatch%2F133517%2F&amp;data=04%7C01%7Cfe
> lix.mo
> >
> essbauer%40siemens.com%7C8e3a031610c74e6dd76c08d9a9caf3f5%7C38ae3
> bcd95
> >
> 794fd4addab42e1495d55a%7C1%7C0%7C637727511405820881%7CUnknown%
> 7CTWFpbG
> >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%
> >
> 3D%7C3000&amp;sdata=od2HCs8VUwZqOzifBdItzcjb5a7j85g33J44%2BiMMjCM
> %3D&a
> > mp;reserved=0
> >
> Default ISAR_RELEASE_CMD can be found in meta/classes/image.bbclass as:
> ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe --tags --
> dirty --match 'v[0-9].[0-9]*'"
> which results in something like `v0.7-534-g6752a45` This issue is reproduced
> inside Jenkins only, but not locally or in gitlab/kas.

Then it's likely that Jenkins modifies files in the source tree.
One thing you could try is to explicitly make the git "dirty", or simply try a static ISAR_RELEASE_CMD.

Anyways, how should we proceed here?

Felix
> 
> --
> Anton Mikanovich
> Promwad Ltd.
> External service provider of ilbers GmbH Maria-Merian-Str. 8
> 85521 Ottobrunn, Germany
> +49 (89) 122 67 24-0
> Commercial register Munich, HRB 214197
> General Manager: Baurzhan Ismagulov


  reply	other threads:[~2021-11-17 15:57 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 11:05 Felix Moessbauer
2021-11-04 11:05 ` [PATCH v4 1/2] always invoke ISAR_RELEASE_CMD to invalidate downstream tasks on change Felix Moessbauer
2021-11-04 11:05 ` [PATCH v4 2/2] Ensure generation of /etc/os-release is idempotent Felix Moessbauer
2021-11-04 13:12 ` [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD Henning Schild
2021-11-16 18:09 ` Anton Mikanovich
2021-11-17 10:45   ` Moessbauer, Felix
2021-11-17 13:05     ` Anton Mikanovich
2021-11-17 15:57       ` Moessbauer, Felix [this message]
2021-11-17 16:39         ` Baurzhan Ismagulov
2021-11-22 15:28         ` Anton Mikanovich
2021-11-24  9:30           ` Schmidt, Adriaan
2021-11-24 10:15             ` Moessbauer, Felix
2021-11-24 11:25               ` Jan Kiszka
2021-11-24 11:54                 ` Anton Mikanovich
2021-11-24 12:11               ` Henning Schild
2021-11-29  9:09                 ` Anton Mikanovich
2021-11-29  9:50                   ` Henning Schild
2021-11-29  9:55                     ` Anton Mikanovich
2021-11-29 13:04                   ` Anton Mikanovich
2021-11-29 13:18                     ` Henning Schild
2021-11-29 14:20                       ` Anton Mikanovich
2021-11-30 10:03                         ` Moessbauer, Felix
2021-12-01 10:39                           ` Anton Mikanovich
2021-12-02 14:55                           ` Anton Mikanovich
2021-12-03  9:51                             ` Moessbauer, Felix
2021-11-24 11:53             ` Anton Mikanovich
2021-11-24 12:35             ` Henning Schild
2021-11-24 12:52               ` Anton Mikanovich
2021-11-17 16:54       ` Henning Schild
2021-11-18  8:36         ` Moessbauer, Felix

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=AM9PR10MB4869539EA113154BACEFB107899A9@AM9PR10MB4869.EURPRD10.PROD.OUTLOOK.COM \
    --to=felix.moessbauer@siemens.com \
    --cc=adriaan.schmidt@siemens.com \
    --cc=amikan@ilbers.de \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    /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