Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quilt vs native methods / release-less builds #1

Open
nicolov opened this issue Jun 18, 2017 · 2 comments
Open

quilt vs native methods / release-less builds #1

nicolov opened this issue Jun 18, 2017 · 2 comments

Comments

@nicolov
Copy link

nicolov commented Jun 18, 2017

Hello, thanks for publishing this. I've watched the ROSCon talk and it was full of good ideas. I have a few doubts though:

  • AFAICT, both the quilt and the native method have the same issue with unrelated catkin packages being pulled into the build when they share a repository with needed packages. Is that correct? If so, I can submit a PR to improve the readme.

  • Regarding the problem above, couldn't we just use the cache to find all recursive dependencies of the "root" package, and generate a whitelist file accordingly? Am I missing something here?

  • Have you made progress on the idea of builds without bloom/release repos? What's wrong with using the version: key in rosdistro to hold a githash instead of a branch?

Thanks

@nicolov
Copy link
Author

nicolov commented Jun 18, 2017

I've found this and understand much more now: the cached package.xml apply to the release repo, not to the source repo. That's why you worked on caching the source manifest as well.

@mikepurvis
Copy link
Owner

mikepurvis commented Jun 19, 2017

Hi @nicolov, thanks for the kind words.

AFAICT, both the quilt and the native method have the same issue with unrelated catkin packages being pulled into the build when they share a repository with needed packages.

Yes, that is correct. Our internal version of this tooling (at Clearpath) computes the dependencies and passes an explicit whitelist as you suggested, but I wanted to keep the example given here simple and straightforward, particularly for an audience with varying exposure to these things.

Have you made progress on the idea of builds without bloom/release repos? What's wrong with using the version: key in rosdistro to hold a githash instead of a branch?

Yes, we now do exactly that in our internal version of this. There's some discussion of the particulars in ros-infrastructure/rosdistro#92. The main reason I don't draw a lot of attention to it in the ROSCon presentation is that source manifest caching never got turned on in the buildfarm due to the overhead of needing to git ls-remote all the repos on each cache rebuild (see the discussion here ros-infrastructure/rosdistro#84 (diff)).

If you're interested to move this forward, I would be delighted to see a PR on the rosdistro repo that would allow updating the source cache only once a day or something (or incrementally), so that it would be possible to have source repo packages available from the buildfarm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants