Yocto Project Discussions
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Cc: yocto@lists.yoctoproject.org, Quentin Schulz <foss+yocto@0leil.net>
Subject: Re: [yocto] [PATCH yocto-autobuilder-helper] scripts: run-docs-build: make the workdir pristine between builds
Date: Mon, 10 Oct 2022 16:34:38 +0200	[thread overview]
Message-ID: <20221010163438.6c2bda32@booty> (raw)
In-Reply-To: <4b6d09f7-f555-7238-e629-78585019a4a1@theobroma-systems.com>

Hi Quentin,

On Wed, 5 Oct 2022 10:55:44 +0200
Quentin Schulz <quentin.schulz@theobroma-systems.com> wrote:

> Hi Luka,
> 
> On 10/4/22 22:54, Luca Ceresoli wrote:
> > Hi Quentin,
> > 
> > On Tue, 4 Oct 2022 10:15:20 +0200
> > Quentin Schulz <quentin.schulz@theobroma-systems.com> wrote:
> >   
> >> Hi Luca,
> >>
> >> On 10/3/22 23:15, Luca Ceresoli wrote:  
> >>> Hi Quentin,
> >>>
> >>> On Mon,  3 Oct 2022 19:04:01 +0200
> >>> "Quentin Schulz" <foss@0leil.net> wrote:
> >>>      
> >>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> >>>>
> >>>> It happened that the git repositories were dirty and resulted in
> >>>> incorrect files being used. Let's use git clean -ffdx to force a
> >>>> completely clean git repositories before and after checking out a branch
> >>>> so that nothing is left from or to another branch build
> >>>>
> >>>> Cc: Quentin Schulz <foss+yocto@0leil.net>
> >>>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> >>>> ---
> >>>>    scripts/run-docs-build | 10 +++++-----
> >>>>    1 file changed, 5 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/scripts/run-docs-build b/scripts/run-docs-build
> >>>> index c6b3965..69e3257 100755
> >>>> --- a/scripts/run-docs-build
> >>>> +++ b/scripts/run-docs-build
> >>>> @@ -61,6 +61,7 @@ for branch in 1.46 $(git branch --remote --contains "$first_sphinx_commit" --for
> >>>>    
> >>>>        echo Building bitbake $branch branch
> >>>>        git checkout $branch
> >>>> +    git clean -ffdx
> >>>>        git checkout origin/master releases.rst
> >>>>        make clean
> >>>>        SPHINXOPTS="-j auto" make publish
> >>>> @@ -80,7 +81,7 @@ for branch in 1.46 $(git branch --remote --contains "$first_sphinx_commit" --for
> >>>>        fi
> >>>>    
> >>>>        cp -r ./_build/final/* $outputdir/bitbake/$branch
> >>>> -    git reset --hard
> >>>> +    git clean -ffdx  
> >>>
> >>> Sure this is correct? 'git clean -ffdx' does not revert changes to
> >>> tracked files, be them staged or not.
> >>>      
> >>
> >> Nope, not sure this is correct. I misread git clean manpage, we should
> >> have a git reset --hard and git clean -ffdx. Now the question is when
> >> those are necessary because with this patch we do it twice, before and
> >> after the git checkout. I did this because I remember doing checkouts
> >> between branches of U-Boot/kernel and while the pre-checkout branch was
> >> not dirty, the after-checkout branch was dirty. I assume this might have
> >> something to do with build artifacts of the pre-checkout build that
> >> weren't .gitignored in the afer-checkout branch? Something that git
> >> clean -ffdx should tackle I think.
> >>
> >> Sooo, I guess only having git reset --hard and git clean -ffdx before a
> >> checkout should be enough and we don't need them both before and after
> >> the checkout like I did in this patch?  
> > 
> > I think 'reset --hard' + 'clean -ffdx' only before the checkout should
> > be enough. However I'm not sure whether there are corner cases such as
> > a file that is .gitignored in commit A and versioned in commit B or
> > similar. Perhaps worth trying with reset+clean only before, and see  
> 
> I guess it does not hurt to be on the safe side by having them before 
> and after the git checkout then? Since the current issue went unnoticed 
> for months...

Sorry for the delayed reply. It took a while before I found a little
time to look at the script code...

Indeed cleaning before _and_ after would be safe, even though perhaps
unneeded.

> > what happens. However I don't know exactly the initial problem you're
> > trying to fix.
> >   
> 
> https://lore.kernel.org/yocto-docs/e50abe3c777e4a23a752a3ec25ad0b2a@axis.com/T/#t

Ah, interesting. Thanks for the link. Why not adding it to your commit
message, for reference?

Best regards.
-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


      reply	other threads:[~2022-10-10 14:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 17:04 [PATCH yocto-autobuilder-helper] scripts: run-docs-build: make the workdir pristine between builds Quentin Schulz
2022-10-03 17:05 ` Quentin Schulz
2022-10-03 17:11 ` [yocto] " Michael Opdenacker
2022-10-03 21:15   ` Luca Ceresoli
2022-10-03 21:15 ` Luca Ceresoli
2022-10-04  8:15   ` Quentin Schulz
2022-10-04 20:54     ` Luca Ceresoli
2022-10-05  8:55       ` Quentin Schulz
2022-10-10 14:34         ` Luca Ceresoli [this message]

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=20221010163438.6c2bda32@booty \
    --to=luca.ceresoli@bootlin.com \
    --cc=foss+yocto@0leil.net \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=yocto@lists.yoctoproject.org \
    /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