<div dir="ltr">Hi,<div><br></div><div>Good move, thanks Alessandro.</div><div><br></div><div>There was recently also a discussion about moving from travis to github workflows.</div><div>In combination with this, I assume the base image could also be cached directly inside the github registry (<a href="https://docs.github.com/en/free-pro-team@latest/packages/guides/about-github-container-registry">https://docs.github.com/en/free-pro-team@latest/packages/guides/about-github-container-registry</a>).</div><div>This might also bring quicker builds because it's in the same network / tightly integrated with the service.</div><div><br></div><div>Just to keep that in mind too</div><div>Matthias</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 4, 2021 at 10:29 AM Alessandro Pasotti <<a href="mailto:apasotti@gmail.com">apasotti@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jan 4, 2021 at 10:21 AM Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br>
><br>
> On Mon, Jan 4, 2021 at 10:17 AM Richard Duivenvoorde<br>
> <<a href="mailto:rdmailings@duif.net" target="_blank">rdmailings@duif.net</a>> wrote:<br>
> ><br>
> > Yes, I hit that too. thanks for bringing this up!<br>
> ><br>
> > Another idea: as the docker is actually more or less 'static' (??? or is is pushed to hub on every build ???), can we (or Travis) not 'cache' it? As in" place it somewhere so it can be 'created/started' fresh any time, but not 'fetched' upon every build?<br>
> > Or does this loose the whole purpose of this...<br>
> > Caching could be: put the image on some webserver of somebody with 'unlimited' bandwidth (like some universities, providers or (unix)usergroups?).<br>
> ><br>
><br>
> I think that might work, the deps image is a base image and it doesn't<br>
> change so often.<br>
><br>
> > BUT: As QGIS is getting bigger and bigger, we have to find solutions for this kind of 'size'-issues when using 'free' services. Same with for example the use of OSM-tiles or Nominatim-service, Transifex etc etc... We have to be either creative/clever, OR setup our own stuff...<br>
> ><br>
> > Regards,<br>
> ><br>
> > Richard Duivenvoorde<br>
> ><br>
><br>
> Yeah, let's just hope GitHub will remain free or we will have bigger problems ;)<br>
><br>
> In the meantime I can fill up the form<br>
> <a href="https://www.docker.com/community/open-source/application" rel="noreferrer" target="_blank">https://www.docker.com/community/open-source/application</a> if noone has<br>
> already done that.<br>
><br>
<br>
<br>
Done ^^^ let's see if that works.<br>
<br>
-- <br>
Alessandro Pasotti<br>
QCooperative:  <a href="http://www.qcooperative.net" rel="noreferrer" target="_blank">www.qcooperative.net</a><br>
ItOpen:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>