Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Sourabh Banerjee" <sbanerje@codeaurora.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [bitbake][PATCH 3/3] bitbake: fetch2/repo: add support for --repo-url and --repo-branch
Date: Sun, 16 May 2021 19:40:03 +0530	[thread overview]
Message-ID: <14c1013e215aa1ea748996664627d649@codeaurora.org> (raw)
In-Reply-To: <060ec8a22677e3e7d22cd07c49dc1abc9ccbbf8f.camel@linuxfoundation.org>

On 2021-05-16 18:13, Richard Purdie wrote:
> On Sun, 2021-05-16 at 16:53 +0530, Sourabh Banerjee wrote:
>> repo tool provides following options to use a stable or preferred
>> version of the tool
>>   repo Version options:
>>     --repo-url=URL      repo repository location
>>     --repo-branch=REVISION
>>                         repo branch or revision
>> 
>> By supplying repo_url=<uri> and repo_branch=<branch> recipe may choose
>> to sync a specific version of repo tool.
>> 
>> Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
>> ---
>>  bitbake/lib/bb/fetch2/repo.py | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/bitbake/lib/bb/fetch2/repo.py 
>> b/bitbake/lib/bb/fetch2/repo.py
>> index e7c5255..902337f 100644
>> --- a/bitbake/lib/bb/fetch2/repo.py
>> +++ b/bitbake/lib/bb/fetch2/repo.py
>> @@ -66,9 +66,15 @@ class Repo(FetchMethod):
>>          repodir = os.path.join(codir, "repo")
>>          bb.utils.mkdirhier(repodir)
>>          if not os.path.exists(os.path.join(repodir, ".repo")):
>> +            repo_url = ud.parm.get('repo_url', '')
>> +            if repo_url:
>> +                repo_url = '--repo-url=' + repo_url
>> +            repo_branch = ud.parm.get('repo_branch', '')
>> +            if repo_branch:
>> +                repo_branch = '--repo-branch=' + repo_branch
>>  
>> 
>> 
>> 
>>              bb.fetch2.check_network_access(d, "%s init -m %s -b %s -u 
>> %s://%s%s%s" % (ud.basecmd, ud.manifest, ud.branch, ud.proto, 
>> username, ud.host, ud.path), ud.url)
>> -            runfetchcmd("%s init -m %s -b %s -u %s://%s%s%s" % 
>> (ud.basecmd, ud.manifest, ud.branch, ud.proto, username, ud.host, 
>> ud.path), d, workdir=repodir)
>> +            runfetchcmd("%s init -m %s -b %s -u %s://%s%s%s %s %s" % 
>> (ud.basecmd, ud.manifest, ud.branch, ud.proto, username, ud.host, 
>> ud.path, repo_url, repo_branch), d, workdir=repodir)
>>  
>> 
> 
> In your other patch you make the new parameters update the mirror 
> tarball 
> name. I'm wondering if we also need to do something like that here as 
> presumably, the fetched output might vary depending on which version 
> of repo was used?

Hi Richard,

Here is what I understand. The 'repo' tool installed on host, let's say 
at /usr/bin/repo
handles the options --repo-url and --repo-branch in 'init' sub-command 
and downloads the
'repo' tool copy from uri-branch under <working-dir>/.repo/repo/repo. 
All subsequent sub-commands
such as 'sync' will work using the tool copy under 
<working-dir>/.repo/repo/repo.
As a recipe developer/maintainer I find --repo-url and --repo-branch 
useful when I know my manifest
has a XML key-value pair that is only supported certain version (& up) 
of 'repo' tool.
At such a point I will code my SRC_URI as
SRC_URI = "\
repo://URI/my-manifest-project.git;\
protocol=git;branch=main;project=platform/my-project;\
repo_url=git://gerrit.googlesource.com/git-repo;repo_branch=stable\
"
Here I thought as my recipe file carries the URI-BRANCH combo to repo 
tool it needs, shall be good?
With this thought I did not code it in mirror tarball name.

> 
> Bitbake patches should go to the bitbake-devel list. I'm also
I have never submitted to bitbake-devel, but I think I will take these 
there then?

> wondering if there should be new fetcher tests these changes should be
> adding to lib/bb/test/fetch.py, run using bitbake-selftest?
Thanks for valuable suggestion, I will look into how tests are developed 
for fetcher.
If possible, please point me to fetcher test, that you consider to be a 
well written one.
I will learn from it.

> 
> Cheers,
> 
> Richard


-- 
Regards,
Sourabh

  reply	other threads:[~2021-05-16 14:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 11:23 [bitbake][PATCH 1/3] bitbake: fetch2/repo: add support for projects to be fetched simultaneously Sourabh Banerjee
2021-05-16 11:23 ` [bitbake][PATCH 2/3] bitbake: fetch2/repo: add support for sync specific projects Sourabh Banerjee
2021-05-16 11:23 ` [bitbake][PATCH 3/3] bitbake: fetch2/repo: add support for --repo-url and --repo-branch Sourabh Banerjee
2021-05-16 12:43   ` [OE-core] " Richard Purdie
2021-05-16 14:10     ` Sourabh Banerjee [this message]
2021-05-16 12:40 ` [OE-core] [bitbake][PATCH 1/3] bitbake: fetch2/repo: add support for projects to be fetched simultaneously Richard Purdie
2021-05-16 13:19   ` Sourabh Banerjee

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=14c1013e215aa1ea748996664627d649@codeaurora.org \
    --to=sbanerje@codeaurora.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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