On Tue, May 6, 2014 at 2:36 PM, Javier Candeira <[email protected]> wrote:
> >> You only need to run the tests for your library when you modify your > >> library. > > How do I do this if I don't know when changes have been made to it? > (Maybe > > another dev changed it, the travis-ci should notice ...) > > Yes, it's now a separate library. It may be in development, but it's > tested separately. > Right. Okay, so I'm very happy if I'm not testing this common "foo" library as part of testing my particular project using it (let's call it Project X.) Well, maybe this solves everything. So we now claim that the ideal set up is: - foo exists as a pip-installable source repo somewhere. - foo has ci testing it for each pull req - each programmer working on project x forks project x *and* foo - foo is included as a "relative subrepo", say, of project x (i'm ignoring this -e option by maybe claiming i'd like this to work for non-python things too) - now i can make changes to foo, commit them to my own repo. say someone else is working on project_x with me; they do pull reqs to me; i am obliged to accept pull reqs to both foo and project_x at the same time. But ... - my dev_foo now needs it's own ci build? (how else will it be auto-tested? or does this only happen on pull reqs up to the guy with the ci build for it?) I guess there are still two problems. The ci builds for foo - who has them? How do they get initiated? Say we're on github with travis. If I pull req to the "main" repo; it will ci build for me. So do I rely on that? Somehow this is now not completely continuous integration. It's some odd version of it; notably, I might not see failures for a long time. The other alternative - creating my own just for the fork - also seems odd. The other problem is that I need to accept pull reqs to foo and project_x in some order, otherwise the build breaks. -- Noon Silk Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ "Every morning when I wake up, I experience an exquisite joy -- the joy of being this signature."
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
