Release automation

[JanCBrammer]

We've started to configure our release automation: https://github.com/IUPAC-InChI/InChI/blob/main/.github/workflows/release.yml.
In short, every time we tag and publish a new release, a GitHub action uploads zip archives according to the convention on https://www.inchi-trust.org/all-downloadable%20versions/.

We could expand this by automatically building / compiling our release artifacts, i.e., the contents of INCHI-1-BIN such as libinchi.so. In order to do that we could write compilation scripts (essentially just calling make like so) which we then run as part of the release automation. By scripting the compilation, we can run it locally as well as during the automation.
@djb-rwth, we'd need to figure out which version of which compiler to run on which OS. That would pretty much be what you documented in the README, right?

Examples:

• https://github.com/igraph/igraph/blob/master/.github/workflows/build-cmake.yml (thanks @flange-ipb)
• https://github.com/OpenChemistry/avogadroapp/blob/master/.github/workflows/build_cmake.yml (thanks @nbehrnd)

TODO:

• remove (and/or .gitignore) all artifacts that are currently distributed as part of the codebase (e.g., all "bin" directories) outside INCHI-1-BIN; keep around (empty) bin directories since they are currently hard-coded into makefiles (0b277e0)
• decide on how to build release artifacts: which compiler(s) to use on which OS (i.e., "release matrix" of compiler by OS) (Build with CMake #112)
• write scripts for each cell in the release matrix (those can be run locally and on ci) (Build with CMake #112)
• remove INCHI-1-BIN; instead distribute artifacts under https://github.com/IUPAC-InChI/InChI/releases (directory structure tbd, but can deviate from status quo)
• decide if we deprecate winchi-1.exe
• decide if we deprecate 32 bit artifacts
• run release workflow only if ci workflow passes for the tagged commit that triggered release
• run tests (which ones?) on release artifacts
• use https://github.com/giallu/InChI/tree/build_matrix as a foundation (thanks @giallu)
• sign artifacts (thanks @MikeWilliams-UK )
• feature suggest: extend version information in the compiled executable #61 (thanks @nbehrnd)

[djb-rwth]

I would not overstretch this whole automation process to compiling + compressing. Releases are more-or-less stable, and all the compiled executables, source codes, .dll/.so files, VS projects, etc. will be provided in the main branch. Creating RWTH releases would just waste our time. Also, CI for VS projects might not be as straightforward and I have done it only on University Azure.

…

________________________________________ From: Jan C. Brammer ***@***.*** Sent: Tuesday, December 12, 2023 15:24 To: IUPAC-InChI/InChI_Dev Cc: Baljozovic, Dorde; Mention Subject: [IUPAC-InChI/InChI_Dev] Release automation (Issue IUPAC-InChI/InChI#1) We've started to configure our release automation: https://github.com/IUPAC-InChI/InChI_Dev/blob/main/.github/workflows/release.yml. In short, every time we tag and publish a new release, a GitHub action uploads zip archives according to the convention on https://www.inchi-trust.org/all-downloadable%20versions/. We could expand this by automatically building / compiling our release artifacts, i.e., the contents of INCHI-1-BIN<https://github.com/IUPAC-InChI/InChI_Dev/tree/main/INCHI-1-BIN> such as libinchi.so<https://github.com/IUPAC-InChI/InChI_Dev/blob/main/INCHI-1-BIN/linux/64bit/so/libinchi.so.1.07.gz>. In order to do that we could write compilation scripts (essentially just calling make like so<https://github.com/IUPAC-InChI/InChI_Dev/blob/main/INCHI-1-TEST/compile_inchi_lib.sh>) which we then run as part of the release automation. By scripting the compilation, we can run it locally as well as during the automation. @djb-rwth<https://github.com/djb-rwth>, we'd need to figure out which version of which compiler to run on which OS. That would pretty much be what you documented in the README<https://github.com/IUPAC-InChI/InChI_Dev/blob/main/README.md>, right? — Reply to this email directly, view it on GitHub<#1>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5BLV6N346PRSUT7OWQINKTYJBSJBAVCNFSM6AAAAABARR5PSSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZTOOBWGQ2DSMI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[fbaensch-beilstein]

We should bring this up for discussion again, as #54 shows. And it would be nice if we could provide artifacts for each "main" OS, see dan2097/jna-inchi#21.

[MikeWilliams-UK]

Possibly add code signing into the pipeline ?

[nbehrnd]

- [ ] decide on how to build release artifacts: which compiler(s) to use on which OS (i.e., "release matrix" of compiler by OS)

Could Avogadro2 by Geoffrey Hutchison et al. on <https://github.com/openchemistry/avogadroapp> serve as of inspiration/experience? This one comes to my mind because the project provides both installers and an AppImage for Windows/Mac/Linux filed on the release page, as well as nightly builds (to catch up with additional translations from weblate, improved avogenerators, bug fixes, etc.) on the project's landing page.