Testing patch v12.0.3

[laurenceisla]

Just testing some cherry-picks with minimal conflicts for a patch release.

The original strategy is to force push the changes in main to the v12 branch. Since only some commits are applied, I based it on the existing v12 branch instead.

---

From the current CHANGELOG, the included fixes are:

• Misleading "Starting PostgREST.." logs on schema cache reloading #3149, Misleading "Starting PostgREST.." logs on schema cache reloading - @steve-chavez
• Wrong subquery returns as 400 Bad Request #3205, Fix wrong subquery error returning a status of 400 Bad Request - @steve-chavez
• fix: Avoid casting to table type when select= and media type handler are used #3224, Return status code 406 for non-accepted media type instead of code 415 - @wolfgangwalther
• Returning mimetypes via aggregates only works for select=* #3160, Fix using select= query parameter for custom media type handlers - @wolfgangwalther
• Inserts and Updates now require an up-to-date schema cache #3361, Clarify PGRST204(column not found) error message - @steve-chavez
• Rejected application/vnd.pgrst.object+json returns the media type sucessfully #3373, Remove rejected mediatype application/vnd.pgrst.object+json from response - @taimoorzaeem
• OpenAPI does not tag a column as FK if it also has a UNIQUE constraint #3418, Fix OpenAPI not tagging a FK column correctly on O2O relationships - @laurenceisla
• View with infinite recursion causes 400 bad request #3256, Fix wrong http status for pg error 42P17 infinite recursion - @taimoorzaeem

The missing fixes are:

• GSSAPI authorization to the database #2815, Build static executable with GSSAPI support - @wolfgangwalther
• --dump-schema does not dump media handlers #3237, Dump media handlers and timezones with --dump-schema - @wolfgangwalther
• fix: don't hide error on LISTEN channel failure #3323, fix: upgrade hasql-notifications to show error #3324, Don't hide error on LISTEN channel failure - @steve-chavez
• Admin server /ready endpoint is incorrect on slow schema cache loads #3330, Incorrect admin server /ready response on slow schema cache loads - @steve-chavez
• fix: log on LISTEN notification #3340, Log when the LISTEN channel gets a notification - @steve-chavez
• pgrst.server_trace_header in-database config not working #3345, Fix in-database configuration values not loading for pgrst.server_trace_header and pgrst.server_cors_allowed_origins - @laurenceisla

[steve-chavez]

Even with just some fixes, a new patch release LGTM. If the others are hard to merge, we can leave them for the next minor.

[wolfgangwalther]

I don't understand why we want a new patch release right now. We agreed in #3113 to work on the next minor release immediately. The docs for the features added before the docs-migration are still missing, though. Instead, we're getting new features worked on all the time. What am I missing?

[wolfgangwalther]

The original strategy is to force push the changes in main to the v12 branch. Since only some commits are applied, I based it on the existing v12 branch instead.

I don't understand what that means. You are proposing to merge this into v12, which was exactly the plan, right? What am I missing?

---

I'd still need to finish the release workflow to make it possible to release on the v12 branch properly. I haven't come around to finishing this, yet.

[laurenceisla]

I don't understand what that means. You are proposing to merge this into v12, which was exactly the plan, right? What am I missing?

No, no, there shouldn't be a problem. Mostly mentioned it because I didn't know if the release workflow may be different between force pushing the main branch and forking and merging the v12 one.

[wolfgangwalther]

Mostly mentioned it because I didn't know if the release workflow may be different between force pushing the main branch and forking and merging the v12 one.

I'm not sure what you mean by force pushing the main branch - but I don't ever want to do that. Maybe there is a mis-understanding. I imagine the future development flow for back-branches to be basically exactly how you did it here: Cherry-pick bugfixes. But then do the cherry-picking + PR semi-automatically and also auto-release bugfix releases after commits to the back-branches, similar to nightly releases on the main branch.

[laurenceisla]

I'm not sure what you mean by force pushing the main branch - but I don't ever want to do that. Maybe there is a mis-understanding.

Ah cool, I get it now. I misunderstood here: #2814 (comment), I now notice that you never mentioned the main branch.

But then do the cherry-picking + PR semi-automatically and also auto-release bugfix releases after commits to the back-branches, similar to nightly releases on the main branch.

Got it.

[wolfgangwalther]

Ah cool, I get it now. I misunderstood here: #2814 (comment), I now notice that you never mentioned the main branch.

Ah, I had forgotten about this. Yeah, we might need to still force push the release branch (v12) after a new minor release. But this should not affect the patch release workflow.

[wolfgangwalther]

I rebased this on latest v12, then ran postgrest-release for this branch (technically needs to run on the branch named v12, so did that locally) and added the resulting bump commit here.

We can merge this into v12 when pipelines pass - this should then kick off the new release, including tag etc. Let's see whether that works.

[laurenceisla]

@wolfgangwalther Great job on the new release workflow, it's looking great!

We can merge this into v12 when pipelines pass - this should then kick off the new release, including tag etc. Let's see whether that works.

Some feedback here:

• The release was generated https://github.com/PostgREST/postgrest/releases/tag/v12.0.3, but the content from the CHANGELOG with the list of Fixes didn't show (I added them manually).

• The Docker release for v12.0.3 does not include the arm64 image. According to the error in the GH Actions, it's using vv12.0.3 as tag, so it mustn't add a v anymore here:

  postgrest/.github/scripts/arm/docker-publish.sh

  Lines 21 to 23 in 1afd98a

  	else
  	PGRST_TAG="v$PGRST_VERSION"
  	fi

[wolfgangwalther]

The release was generated https://github.com/PostgREST/postgrest/releases/tag/v12.0.3, but the content from the CHANGELOG with the list of Fixes didn't show (I added them manually).

Haha, I was heavily confused when I just got a notification for the release without any notes - and then clicked the release and all notes were there... ok I will investigate.

The Docker release for v12.0.3 does not include the arm64 image. According to the error in the GH Actions, it's using vv12.0.3 as tag, so it mustn't add a v anymore here:

Argh. I only introduced that conditional logic because I had vdevel tags on main with the exact same result... turns out I should have just removed the v prefix entirely...

[wolfgangwalther]

According to the error in the GH Actions,

I wonder why we have an error here... but the job still passes. Seems like there is no error code returned.

[wolfgangwalther]

Ok, I fixed all three issues. To get the arm docker image properly build and pushed, I will need to re-run the whole release pipeline - to not make it fail, I will delete the github release soon, it will then be recreated again when I force push the v12.0.3 tag to after my fixes.

[wolfgangwalther]

While fixing the error codes for the arm scripts.. I realized that this was broken ever since 83cf15f, which was supposed to pass a GHC_VERSION argument. But GHC_VERSION is not $GHC_VERSION - and thus ghcup was always throwing errors when trying to install that literal GHC_VERSION string. But nobody noticed, because those scripts weren't set -e.. :/

Let's see what that means. Hopefully things will just build fine when we now pass the proper version to it.

[wolfgangwalther]

Hm, the latest push for the tag failed with a "no space left" error for the arm job: https://github.com/PostgREST/postgrest/actions/runs/9022807863/job/24793212610

This might be because too many arm jobs were running at the same time. Just to be sure, @laurenceisla, can you check on the runner again whether we might have left-over build folders again which were not cleaned up?

I will wait a bit until all other jobs have settled down and then run it again.

[wolfgangwalther]

This might be because too many arm jobs were running at the same time. Just to be sure, @laurenceisla, can you check on the runner again whether we might have left-over build folders again which were not cleaned up?

If you happen to have a chance to look into this before I do again tomorrow, you can also restart the failed jobs in this pipeline: https://github.com/PostgREST/postgrest/actions/runs/9022807863/job/24793212610 - this should then continue the release pipeline. I'll look into it tomorrow again.

[laurenceisla]

But GHC_VERSION is not $GHC_VERSION - and thus ghcup was always throwing errors when trying to install that literal GHC_VERSION string.

Ooph, nice catch.

If you happen to have a chance to look into this before I do again tomorrow, you can also restart the failed jobs in this pipeline: https://github.com/PostgREST/postgrest/actions/runs/9022807863/job/24793212610 - this should then continue the release pipeline. I'll look into it tomorrow again.

That's strange, the server doesn't seem to have older build folders there... maybe with the GHC fix, it added more libraries to the .cabal folder. I'll check it out and will restart when I find the culprit.

[laurenceisla]

It was GHCup itself that had GBs of tmp files while installing, I think both CI jobs for main and v12.0.3 collided in installing their GHC versions. Anyways, I nuked the whole ghcup/cabal and reinstalled again. I'm also restarting the jobs with the one in main first.

[laurenceisla]

All done! it's working correctly now 🎉

Confirmed that both of the issues mentioned here are fixed #3443 (comment).