Opened 13 days ago
Last modified 12 days 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 -qdoes not printpre-X.YbutX.Y), change settings (filenames,BUILD_INFO, ...) accordingly. - Adjust
do_releasescript: 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 , 13 days ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:2 by , 12 days ago
comment:3 by , 12 days 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.
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.