search

dpage / winpgbuild

A repo containing Github actions for building PostgreSQL and it's dependencies on Windows
1 stars 2 forks source link

Allow building git snapshots #9

Closed anarazel closed 1 month ago

anarazel commented 2 months ago

Hi,

To be able to a) test some of the meson changes b) test before releases we need to be able to test git branches / hashes / something.

For now I've just hacked up postgresql-dev.yml to check out a hardcoded git repo / branch, but that's clearly not the right approach.

Perhaps postgresql-dev should just always build via git? E.g. configured via POSTGRESQL_DEV_REPO, POSTGRESQL_DEV_REFNAME, which'd allow checking out branches, tags and commits. IMO there's not much point in going through tarballs - using git tags is imo better.

If we do want to continue acquiring via https, perhaps we could make postgresql-dev.yml use a matrix to support both? Duplicating the code seems like it'd be a waste.

Happy to discuss this another way too...

Greetings,

Andres

davecramer commented 2 months ago

Seems to me building from git is the way to go.

anarazel commented 2 months ago

Seems to me building from git is the way to go.

Cool. Do you want to do so for > 16 or also for before? That might require some minor changes besides the checkout, because in the past the tarball contained bison/flex output etc.

davecramer commented 2 months ago

Seems to me building from git is the way to go.

Cool. Do you want to do so for > 16 or also for before? That might require some minor changes besides the checkout, because in the past the tarball contained bison/flex output etc.

Well, my needs are to be able to build psqlODBC so I guess I really only need >16. However, I'm not sure what @dpage envisioned here.

dpage commented 2 months ago

postgresql-dev was really only added so I could start working on meson support, as I couldn't figure out a non-hacky way of dealing with a matrix build that included a beta/rc versioned release.

I think updating it to build from a specific tag or ref etc. is a great idea.

I don't think there's any need to support < 17 though.

anarazel commented 2 months ago

I think updating it to build from a specific tag or ref etc. is a great idea.

Cool, will submit something.

I don't think there's any need to support < 17 though.

The only concern I have there is that eventually 17 will be released and 18 and ... and we'll need a matrix for that too. I was wondering if postgresql-dev should just be merged into postgresql.

davecramer commented 2 months ago

yes, we might as well start adding the matrix in now even if it only includes 17

anarazel commented 2 months ago

yes, we might as well start adding the matrix in now even if it only includes 17

What I wonder about is merging the two files. Maintaining them separately seems not a good bet medium-long term...

davecramer commented 2 months ago

yes, we might as well start adding the matrix in now even if it only includes 17

What I wonder about is merging the two files. Maintaining them separately seems not a good bet medium-long term...

For now they seem too complicated to merge. Agreed

dpage commented 2 months ago

I had always intended to merge postgresql-dev.yml into postgresql.yml, once I had it all working - though that was when it was building the tarballs though.

One reason why I didn't do that originally was that I couldn't see a clean way to do something like: if: ${{ matrix.version >= 17 }} when the version is something like 17beta1, thus my plan was to do that merge once we hit 17.0.

With the new plan being to have postgresql-dev build from git refs/commits/whatever, I suspect we will have to keep it separate, or get really cute with the way the matrix is defined.

anarazel commented 2 months ago

With the new plan being to have postgresql-dev build from git refs/commits/whatever, I suspect we will have to keep it separate, or get really cute with the way the matrix is defined.

Heh, the matrix definition is actually what made me wonder about using git checkouts for the older branches too. That'd make that aspect a lot simpler.

I don't think the version parsing part is that hard - we could have one step parse the version with shell or whatnot and have that step populate a variable that's used by later steps to decide whether to run the src/tools/msvc or meson build.

dpage commented 2 months ago

Oh yes, it's not difficult to make it work. Just kludgy and inelegant.

dpage commented 1 month ago

postgresql-dev now pulls a git ref (specified in the version field in manifest.json) and builds/tests that. I've set it to "master" for now.

Note that it only supports Meson builds.