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.