Use repo tool to clone all needed repositories. #20
Conversation
| @@ -26,38 +26,3 @@ sudo mkdir -p /var/cache/pbuilder/hook.d/ | |||
| cp configs/pbuilderrc ~/.pbuilderrc | |||
| sudo cp configs/D70results /var/cache/pbuilder/hook.d/ | |||
|
|
|||
There was a problem hiding this comment.
Why not add the fetching and running repo here?
There was a problem hiding this comment.
Hi Erich, I'm understanding that this usage flow would be:
- repo init to default.xml in stx-packaging
- repo sync to get stx-packaging, other tools and starlingx repos (instead of git clone)
- then cd stx-packaging and run setup.sh. Now the setup.sh script there won't manage tools and repos, but it'll install dependencies and create directories for the usage of stx-packaging
If that's correct, I've some questions regarding where the repo sync is performed. Besides that, this proposal LGTM.
setup.sh
Outdated
| fi | ||
| done < $filename | ||
| echo "Set up complete" | ||
| repo sync -j4 |
There was a problem hiding this comment.
I think .repo directory is one directory up, in the same level as this stx-packaging. Am I missing something?
README.md
Outdated
| The development tools and git repositories that you need are installed by | ||
| running setup.sh | ||
|
|
||
| ``` | ||
| bash setup.sh | ||
| cd stx-packaging |
There was a problem hiding this comment.
before cd stx-packaging, isn't a repo sync needed?
There was a problem hiding this comment.
Yes, you are correct, I got confused in my environment as I already have stx-packaging cloned. I'm fixing this.
Signed-off-by: Erich Cordoba <[email protected]>
|
Thanks a lot for this PR , I really appreciate all the help provided. Despite the fact that I have my personal opinions about repo I believe that the rich of the open source cam from multiple perspectives to solve complex problems. due to this my request for this PR would be to make it possible to live in both ways. If the developers prefer to use repo is fine, if the developers prefer to use the setup.py could also be fine. The only strong opinion that I have is that if this PR is merged as it is it will break the capability to build inside ubuntu containers since they call setup.py to clone all the necessary repositories. In general, I like the idea as long as it does not break setup.py and both can coexist. Also on the middle of all the high priority reqeust, we have this might not be on the top ones. Let's focus on the top ones. not saying I discourage the free to develop, I really appreciate this PR and the time spent on it, I'm just saying lets sync to work on the blockers we have right now. |
Actually the idea behind this PR is to discuss possible alternatives for repository management. What cons do you see on
I wasn't aware of how the code is cloned inside the container. I'll think in a solution for this. Thanks for the feedback. |
Let's all agree as a community on what is best for the project, maybe repo has evolved since the last time I use it ( 10 years ago ) . I will take a test to your PR and write my impressions
if [ repo is installed and configured] : else :
|
Repo has definitely evolved and matured, I think you have suggested a good compromise below that will allow repo to be used or to use a local direct clone. I would also like to say that while this is a good change, we should focus on getting the basic functionality and infrastructure in place before we start tweaking with the workflow too much. Sau!
|
This is a proposal to use
repoto handle all repositories that needs to be cloned as a requirement.The advantage is that we don't need implement any repository management, all can be done with
repo.The drawback is that
reponeeds to be installed prior of cloning this repository.Other possible solution would be to use git submodules, however that could add a bit more complexity for developers.
Signed-off-by: Erich Cordoba [email protected]