ci: introduce nightly release job

[develop7]

This PR introduces packaging and uploading successfully built artifacts to nightly GitHub release right away, before/without passing test suite.

fixes #2997

[develop7]

Okay, there's two issues at hand:

• uploading the asset fails like this — https://github.com/PostgREST/postgrest/actions/runs/6576825916/job/17867090122?pr=3003#step:7:119. I've created a ticket with GitHub support
• there's no zip on Windows (this one is probably easy one)

[develop7]

• uploading the asset fails like this — PostgREST/postgrest/actions/runs/6576825916/job/17867090122?pr=3003#step:7:119. I've created a ticket with GitHub support

Support got back to me to me and pointed out that PR actions are executed in context of PR creator, so no write access to postgrest/postgrest's releases. However, I can write to my own releases, which I've just tried in a6177ab

[develop7]

Anyway, I've just tested uploading arbitrary files to specific release with GH API and personal access token with "Contents" permission and it worked like a charm, see README.md in https://github.com/develop7/postgrest/releases/tag/nightly

The "zip" issue might require extracting "upload to nightly release" to separate step, so it would run on latest ubuntu all the time and have zip all the time too.

[laurenceisla]

so no write access to postgrest/postgrest's releases.

Yes, the release should not be executed in that part of the process, otherwise, this will be executed any time a PR is done for instance. It should only trigger when it's merged to main. You could add a conditional there, but I think it's better to adapt the Prepare-Release and Release-Github jobs.

For example, Prepare-Release needs an additional check to verify that we're on the main branch:

if: {{ startsWith(github.ref, 'refs/tags/v') || github.ref == 'refs/heads/main' }}

In its body you can use extra conditionals to verify if it's a nightly release.

if [ $GITHUB_REF == "refs/heads/main" ]; then
    echo "isnightly=1" >> "$GITHUB_OUTPUT" #this can be used as output for other jobs
fi

# Then conditionally set version to 'nightly' using

if [ -n "$isnightly" ]; then
    echo "version=nightly-$(date +%Y-%m-%d-%H-%M)" >> "$GITHUB_OUTPUT"
elif [ "$tag_version" != "v$cabal_version" ]; then
    echo "Tagged version ($tag_version) does not match the one in postgrest.cabal (v$cabal_version). Aborting release..."
    exit 1
else

#...

Then you can use that output for the Release-Github job (remember that the Github release won't be nightly-<date>, only nightly). You won't need the extra action.yaml for nightly builds which avoids repeating code (tar and zip processes). I think it's OK that it waits for tests to pass.

I'll give you a hand with the docker release, since I have access to the ARM server in my test repo.

[laurenceisla]

BTW, I added a PR #3051 that supports docker deployments for nightly releases. WDYT about my proposal? Feel free to let me know if you find something amiss, or if you have any doubts.

[develop7]

@laurenceisla thank you for the review and the input. Let me cut to the chase first — CI jobs of this PR cannot upload files to this repo's nightly release because the creator of this PR, me, doesn't have sufficient permissions for this. Moreover, somehow this job is also unable to upload files to my personal fork's releases. In order to have those permissions, I think I have to be promoted to, I guess, a maintainer role (or a custom role with release management permissions, but it requires GitHub Enterprise). Since it's probably too soon for me, I suggest adopting this PR and respective code branch by https://github.com/PostgREST/postgrest/ and someone with enough permission to test it to work.

Yes, the release should not be executed in that part of the process, otherwise, this will be executed any time a PR is done for instance.

I've had issues setting up local run/debugging the pipeline, so triggering a run here is kind of a way to test changes and debug them. Although there seem to be a way to run https://github.com/nektos/act with rootless podman, and I'll give it a try later today.

It should only trigger when it's merged to main.

Absolutely, I intend to add the check for main branch last thing before merging it.

I think it's better to adapt the Prepare-Release and Release-Github jobs.

I've tried to do this initially, but subtle differences were piling up, so I've decided to pursue it in isolation to see if that's possible at all. And it is, almost.

BTW, I added a PR #3051 that supports docker deployments for nightly releases.

Looks great, it's definitely something I wasn't covered yet.

[laurenceisla]

Although there seem to be a way to run https://github.com/nektos/act with rootless podman, and I'll give it a try later today.

That's really cool! I'll also try it, maybe that'll save me the hurdle of testing these actions by pushing in a different repo.

I've tried to do this initially, but subtle differences were piling up, so I've decided to pursue it in isolation to see if that's possible at all. And it is, almost.

I still think it's better that way, mostly due to repetition of steps. But yeah, you can test it in isolation and then I could help migrating to these steps, if it is possible.

[laurenceisla]

@develop7 Is it OK if I continue from here? Since I have access/permissions it'll be easier for me to test any changes.

[develop7]

Yes, absolutely

…

On Wed, Nov 22, 2023, 17:54 Laurence Isla ***@***.***> wrote: @develop7 <https://github.com/develop7> Is it OK if I continue from here? Since I have access/permissions it'll be easier for me to test any changes. — Reply to this email directly, view it on GitHub <#3003 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAV6INVHA4DENIABHWBGSTYFYU3NAVCNFSM6AAAAAA55ZYQNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRTGE2DEMJZHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wolfgangwalther]

Is this superseded by #3051 and #3108?

[laurenceisla]

Is this superseded by #3051 and #3108?

Yes, it is! Closing rn.