Multi-version testing - #929
Conversation
7c77136 to
667c650
Compare
667c650 to
50ca047
Compare
|
I'll give this a review when I have time, but I still think this would add more trouble than it would save. See #710 and npgsql/npgsql#2477 (comment) |
|
|
||
| - bash: sudo sh .build/setup_postgres.sh | ||
| - bash: | | ||
| docker exec -d $[variables['postgres_service']] apt-get -y install postgresql-11-postgis-2.5 |
There was a problem hiding this comment.
Just a thought @austindrenski: I wonder if getting PG via docker can't speed up our build regardless of multi-version testing. I can see that PostgreSQL installation takes around 1 minute 40 seconds in current builds, maybe this could be sped up?
Then again, we'd have wire up all the proper extensions/configuration (PostGIS, SSL, prepared transactions...), not sure it's worth the bother.
There was a problem hiding this comment.
I've had the same thought. In the long run, I think it's worthwhile to at least kick the tires here.
There was a problem hiding this comment.
The docker startup time ~35 seconds. So, definitely some value here.
For now, we're only getting this benefit on the Linux job, as it appears that AP doesn't currently support using Linux service container from a Windows agent job. But we might get to sidestep that altogether by building the jobs within containers too. Further testing needed, though.
Take a look at build 149 build 150 for a good example. It failed, but only because our test suite isn't super version-aware at the moment.
edit: Windows build failed on 149 due to a bad script
There was a problem hiding this comment.
Going the Docker route, the Linux build time drops to 5:46 of which 4:20 was test execution. Whereas the windows side finishes in 12:08 of which 8:52 was test execution.
It doesn't seem like there's an off-the-shelf image for what we need (e.g. Windows + PostgreSQL + PostGIS), so containerizing the whole thing might require us to layer our own image based on something like https://github.com/appropriate/docker-postgis.
I think there's some upside to exploring this further, including future proofing us against future CI changes, and making it easier to reproduce the exact CI environment locally.
(Still all conditional on the maintenance/usefulness trade-off, and our ability to avoid building all of the images from scratch.)
9d51230 to
afb5892
Compare
7f97a2f to
6106a54
Compare
|
TODO:
|
580d64b to
2cf729b
Compare
- Fixes for PG 9.6 and 10 (partial)
- GitHub releases
- Pack regular NuGet packages (i.e. non-CI version numbers).
- Turns out that Build.{Artifact,}StagingDirectory are the same,
so going with the shorter for clarity.
This may cause conflicts with npgsql#943
2cf729b to
345445f
Compare
|
One more idea: why don't we starting running tests on PostgreSQL 12 beta1 as well? It will allow us to start working on new PG 12 features (I'm thinking about generated columns in particular), and would in theory flush out any breaking changes on the PG side. |
|
Testing against the betas sounds like an excellent idea. I'll look into wiring that up as part of phase 3. |
Not sure if this is going to work yet, but Azure Pipelines offers 10 parallel jobs, so why not give it a try.
This almost works right now, but the standard PostgreSQL image (obviously) doesn't include PostGIS, so we need to work out how to add that to it.
Related
#646
#928
#934