On Thu, Jul 20, 2017 at 9:29 AM, Matthias Kuhn <[email protected]> wrote:
> On 7/20/17 8:56 AM, Alessandro Pasotti wrote: > > That's very interesting, Alessandro > >> >> How are dependencies built, using some packaging system or a set of >> scripts? Are the scripts or recipes around somewhere? >> > > Oh, sorry for not being clear, we are not building dependencies but only > QGIS itself, but I think that the general workflow could be used for > building the dependencies in the docker instead of QGIS and push the image > to docker HUB. > > > So, when Travis starts, it will pull the pre-built docker image with all > dependencies already built and either install them in Travis and build QGIS > or build QGIS inside the docker "inside" Travis. > > > BTW, the recipes are here: https://github.com/boundlessgeo/qgis-testing- > environment-docker > > > Thanks for the pointer. > So you are mostly using the dependencies directly from Ubuntu 16.04 except > for one dependency that you build? > Yes, the purpose of that docker is provide a testing environment for plugins, in that context, QGIS is "the" dependency that is being built. > > > >> We were wondering if this could be done directly on travis before the >> build starts (skipping any package that is already up to date in the cache). >> > > >> The nice benefit of this compared to a separate build as you are doing on >> AWS would be that if something needs a new dependency (thinking of qca, >> qtkeychain, ...) it can directly integrated in the same pull request. >> What do you think about this approach? >> >> Thanks >> Matthias >> >> > > I'm not sure I get it right, do you mean that you want to build the > dependencies on Travis within the same job that builds QGIS? > > Correct > > > I think that this would add a considerable time, that's why we are > building on AWS and pull the pre-built docker, but I guess that the goal is > completely different. > > Normally they should be cached and not rebuilt. > Oh, I see, I would not know how to do that though. > I was thinking that the dependencies do not vary frequently, hence we > should be able to build the dependencies docker nightly and when the main > QGIS Travis job starts we can pull the docker with the dependencies > substantially lowering the time needed to run the entire job. > > I imagine version updates happen more often. For example a new gdal > version that brings in some geopackage functionality which is covered by a > unit test. > More often than daily? I was thinking at building the dependencies in the docker daily with AWS. We could even have different set of dependencies in different docker tags and use a Travis matrix to test them all ... given that it does not add too much to the Travis allowed time. > > What's the workflow here? > > If this can be added directly inside a pull request this has some > advantages like > > a) responsibility (even without commit rights on the qgis repo you can > build the deps in the pull request) > b) sandboxing (if the library is updated in a centralized repository and > the new gdal version kills some other unit tests we will have that also > failing on master). > > That's a big advantage, I agree. The bottomline is that if you know how to do that and it will work without timing out, your solutions is for sure the best one. Cheers -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
