Opened 2 months ago

Last modified 2 months ago

#1825 accepted enhancement

Use the CI build process also for official releases

Reported by: Christian Franke Owned by: Christian Franke
Priority: major Milestone: Release 7.5
Component: all Version:
Keywords: Cc: Alex Samorukov

Description

Release source tarballs and the related *.dmg and *-win32-setup.exe binary packages should use the same build process as the CI builds.

This was not the case in the past. Source tarballs were created locally with the do_release script. In particular the files generated by GNU autotools depend on autotools version and may even include hidden differences. This fact has been used in the xz-attack.

The binary packages were built using the CI docker image, but with slightly different settings (different filenames and BUILT_INFO, ...) which were not published.

The -1 suffixes of the binary packages should be dropped, see related comments in ticket #1823.

TODO:

  • Adjust CI build recipes: detect release commits (.\getversion.sh -q does not print pre-X.Y but X.Y), change settings (filenames, BUILD_INFO, ...) accordingly.
  • Adjust do_release script: Drop build of source tarball, do release signing in a separate step (still needs to be done locally as we don't want to upload the private key anywhere).

Possible future release workflow:

  • do_release
  • Run CI builds locally using a local build(!) of the CI docker image.
  • Compare results with the automated public CI builds.
  • If not identical, abort release and investigate.
  • Sign the release files.
  • Upload the release files.

The CI builds run locally cannot use the CI *.yml files directly. Therefore it would make sense to move the embedded complex command sequences to new separate bash scripts which are part of the smartmontools source and then simply call these scripts from the *.yml files.

TBD: Additional steps for a possible release of the windows package signed by SignPath (e.g. compare the unsigned package, check signature, ...).

Change History (3)

comment:1 by Christian Franke, 2 months ago

Owner: set to Christian Franke
Status: newaccepted

comment:2 by Alex Samorukov, 2 months ago

My gentle proposal is to move to git first and then work on release machinery. I'm happy to help on that; just having this with svn2git would eliminate a lot of pain with native git usage.

comment:3 by Alex Samorukov, 2 months ago

p.s. i would also consider switching to gh actions from the CircleCI. Fewer integrations == less pain, and we need the bare minimum from CI.

Last edited 2 months ago by Alex Samorukov (previous) (diff)
Note: See TracTickets for help on using tickets.