Skip to content

Trial run of GitHub Actions build with MinGW against runner-supplied MSVC PG #3

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

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

jcflack
Copy link
Owner

@jcflack jcflack commented Sep 23, 2020

No description provided.

jcflack and others added 16 commits August 31, 2020 19:16
One to build with varying OS and JDK but the version of PostgreSQL
preinstalled in the runner environment, and one that also builds
PostgreSQL from source (or will, when completed).
For this workflow, using the runner-supplied PG, it can just be
pg_config and rely on the PATH. Which would be the default if it
were not supplied, but more of the script would have to be touched
to remove uses of the variable than just to set it to pg_config.
The preceding commit clearly showed that sudo -E did what it
says on the tin, preserved the environment, JAVA_HOME was
pointing to 9 in the sudo environment, and sudo -E java still
ran 8.

Huh?

Anyway, with this working, expand the matrix a little.
In this particular workflow (relying on the PostgreSQL preinstalled
on the runner), this step won't work, because the preinstalled PG
was built with MSVC. But this gets the pieces in place. It would work,
in a workflow where the PostgreSQL was built by MinGW; it would even
work in this workflow, if we give pljava-so a set of rules for building
with MinGW against an MSVC-built PostgreSQL.
The Windows runner seems to have an extra pg_config somewhere on the
path, that reports it was built with MinGW and installed in paths
containing Strawberry that don't really exist.

It has cropped up for others too in other settings:
timescale/timescaledb#555

The pg_config found in $PGBIN refers to a PostgreSQL that was built
with MSVC, and its reported directories really exist. Specify that one
explicitly when running on Windows.

In passing, avoid trying to run the jshell install-and-test with Java 9
in Windows (it will wait forever for someone to type on the console).
Using the bash environment in Windows offers the convenience of
one scripting language to tee up the install-and-test, but at the cost
of getting paths we need (jdbcJar and mavenRepo) munged into Unix style.
They have to be unmunged, as the Windows native Java can't use them
that way.
It can't work in this workflow, where the supplied PostgreSQL
was built with MSVC, at least for now.

Re-enable the Linux and Mac builds to make sure the MinGW
changes didn't break them.
Structure the matrix in each the same as in ci-runnerpg.yml
(except that both of these will have a choice of PostgreSQL
version, rather than being stuck with the version supplied
on the runner).

Both of these need to be completed, of course.

There is much duplication among these three workflows (pretty
much everything after installing or building PostgreSQL). They
will probably be easier to get working that way. After most of
the tricky bits have been worked out, it may be possible to
combine them all into one giant uberworkflow with a lot of
conditional steps. That feels like premature optimization for now.
The dfa() method has been renamed stateMachine() in master.
Trial run of GitHub Actions to build with MinGW against the MSVC-built
PostgreSQL supplied on the Windows runner.
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

Successfully merging this pull request may close these issues.

2 participants