Publish build artifacts to the `Releases` section of the GitHub project.

[fdcastel]

The current release process is currently being done manually (I believe) and involves editing the Wiki homepage.

Ideally, each release should be published into Releases section of the project.

Why am I asking this? Because I'm also the maintainer of the firebird-odbc chocolatey package, and I'm trying to automate it, too 😅.

With the build artifacts being published to GitHub Releases, we can easily retrieve them via the GitHub API. An example of this can be seen in the Firebird-Docker project.

[fdcastel]

Just for the sake of completion.

Today we have the following artifact listed on the Wiki homepage as the download for Windows:

https://github.com/FirebirdSQL/firebird-odbc-driver/actions/runs/11053399614/artifacts/1982531858

However, this is a .zip file containing both x64 and x86 installers.

For the chocolatey package, we need each installer to be available separately for download, similar to what was done on SourceForge.

[irodushka]

Well...

I don't think making a release for every bugfix is ​​a good approach) The release is something of a milestone and should contain some significant changes.
From the other hand, I understand your problem, appreciate your work and would like to help.

The builds are not manual, I have a "git actions" for it - one for Windows and second for Linux. Every commit in master (e.g. merging a pull-request) triggers an automated build process. Yes, editing the wiki page is done manually)) but links lead to git action artifacts. Packing artifacts into a zip archive is the default behavior of the git action publishing step, maybe it can be changed with some settings, I have to investigate.

But. Maybe we should integrate our automation processes?
Theoretically, I could push something to inform your automated process about the new build, and also provide it with links to artifacts?..

[fdcastel]

I don't think making a release for every bugfix is ​​a good approach

Agreed. It wasn't my intention to suggest the opposite. 👍🏻

Packing artifacts into a zip archive is the default behavior of the git action publishing step, maybe it can be changed with some settings, I have to investigate.

Perhaps we could learn from the experience of the Firebird project maintainers, as they are already implementing this.

@asfernandes, @dyemanov or @pcisar: could you shed some light on the subject?

Maybe we should integrate our automation processes? Theoretically, I could push something to inform your automated process about the new build, and also provide it with links to artifacts?

That would be great. However, to the best of my understanding, the Releases section of GitHub addresses exactly this issue, as it can be easily queried via GitHub REST API.

[asfernandes]

Today we have the following artifact listed on the Wiki homepage as the download for Windows:

https://github.com/FirebirdSQL/firebird-odbc-driver/actions/runs/11053399614/artifacts/1982531858

This is problematic. Artifacts of actions may expire.

Perhaps we could learn from the experience of the Firebird project maintainers, as they are already implementing this.

Yes. Actions may run for a tag and then publish the package as a release.

[irodushka]

@asfernandes @fdcastel

Yes, actions can be triggered by a tag and a release can be made (with the corresponding arfifacts), but I'll repeat myself - this is not suitable for a regular bugfix like build 3.0.0.12. Sooner or later I will definitely publish a new release (3.0.1 I suppose), but it should include a significant changes compared to 3.0.0.

What can I do for you now:

1. Split one zip into three:

• VirusTotal verification links - if necessary, you can follow them to make sure the files are clean.
• Win32 installer
• x64 installer

2. Every artifact has a unique ID and a download URL, like this:
   VirusTotalScan: Artifact ID is 1988077820, URL is https://github.com/FirebirdSQL/firebird-odbc-driver/actions/runs/11073121034/artifacts/1988077820
Win32Installer: Artifact ID is 1988077881, URL is https://github.com/FirebirdSQL/firebird-odbc-driver/actions/runs/11073121034/artifacts/1988077881
x64Installer: Artifact ID is 1988077969, URL is https://github.com/FirebirdSQL/firebird-odbc-driver/actions/runs/11073121034/artifacts/1988077969

3. You can use this API: https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28

4. I can do something at the end of the build action workflow to signal a new build/artifacts if you tell me what to do. Maybe I should post something (like an artifact ID) to some URL... as you wish)

[mrotteveel]

You can publish the artifacts from a build for a tag automatically to make a release. For example, using ncipollo/release-action.

There are probably also other actions out there to do this, but I use this one to publish the tagged releases of ext-table-gen. Specifically see the create-release job in https://github.com/mrotteveel/ext-table-gen/blob/main/.github/workflows/publish.yml

[asfernandes]

Yes, actions can be triggered by a tag and a release can be made (with the corresponding arfifacts), but I'll repeat myself - this is not suitable for a regular bugfix like build 3.0.0.12. Sooner or later I will definitely publish a new release (3.0.1 I suppose), but it should include a significant changes compared to 3.0.0.

Ok, and in this case it looks wrong for me that a non-official build is being released in chocolatey.

[irodushka]

Build is official, master branch, but build != Release.

Well, another way is to wait for the next release) We can schedule a cumulative bugfix release on Dec 01, 2024, for example. And then publish official releases every 3 months.

[fdcastel]

@irodushka, could we revisit this topic?

Now that version 3.0.0 has been officially released, and based on the details available in the wiki, I’d like to propose that we publish the following versions to the project's Releases section:

• 3.0.16 (latest)
• 3.0.15
• 3.0.12
• 3.0.11

With each release including separate assets for each supported OS and architecture.

Please also refer back to my earlier messages in this thread. We need each installer/architecture to have a distinct download URL.

The GitHub Releases API makes it possible to fully automate this workflow. You can see an example implementation in the firebird-docker project.

The current structure is quite inconvenient. Not only would I need to implement custom code to work around an issue already solved by the GitHub Releases API, but users are also forced to download unnecessary bundled files containing both 32-bit and 64-bit binaries (only to discard the ones they don't need).

Also, the changelog is quite dated. Compare it with the Jaybird releases.

[mrotteveel]

Just for information, I create the Jaybird releases on GitHub manually, and the notes on the Jaybird releases page are sourced from the full Jaybird release notes, like https://firebirdsql.org/docs/drivers/java/6.0.x/release_notes.html

[fdcastel]

Thanks for chiming in, @mrotteveel!

I'm curious: are you doing the releases manually just due to a lack of time to write automation scripts, or was there another blocker?

At our company, we use GitLab, so I haven’t had much hands-on experience with GitHub Actions until now. But, as I promised @asfernandes, I’m currently learning it. (Right now, to be honest... 😅)

I’d be more than happy to help you guys (@irodushka and @mrotteveel) automate the release process.

@asfernandes also has significant experience in this area (his fantastic work on the Firebird project speaks for itself) so I’m sure he could lend a hand as well.

[mrotteveel]

I've automated the release of ext-table-gen (see one of my earlier comments); I haven't automated the release of Jaybird, because I don't want my Maven Central publishing credentials nor my GnuPG credentials on GitHub in any form.

[mrotteveel]

I could probably add some additional things in my Gradle script to actually create the release on GitHub from my computer as part of the publish, but doing that part manually is not actually that much work.