You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the test task of the GitHub CI workflow errors out on the package hash tests. Find out why exactly and fix the tests accordingly.
Details
I thought the reason for that was that after checking out the repo on a Linux box (during the CI workflow) the timestamps of the files we package up in the tests would be different each time, so the package hash would be too. That is, even if the files that make up the package are always the same, their mod/change/access time can be different at different times. Besides a fresh check out, this could also happen e.g. when merging a branch, opening one of the files locally, etc.
So I've implemented a fix to try making reproducible package hashes in our test cases by setting the mod/change/access time to the epoch's start. (That obviously entailed making the tgz lib more flexible to cater for that.) The approach/fix works fine on my macOS box (TM) but for some obscure reason it breaks on the Linux CI's.
Failed test run output
go test ./... -coverprofile cover.out
? github.com/martel-innovate/osmops [no test files]
? github.com/martel-innovate/osmops/controllers [no test files]
ok github.com/martel-innovate/osmops/osmops/cfg 0.007s coverage: 99.0% of statements
ok github.com/martel-innovate/osmops/osmops/engine 0.012s coverage: 100.0% of statements
ok github.com/martel-innovate/osmops/osmops/nbic 0.027s coverage: 99.5% of statements
--- FAIL: TestPackOpenLdapNs (0.00s)
build_pkg_test.go:96: want hash: cae[45](https://github.com/martel-innovate/osmops/runs/7957977761?check_suite_focus=true#step:7:46)06d23753ee95f21faf8c6f97eaa; got: 2767580693666c3cfdfd8c758b902b80
--- FAIL: TestPackOpenLdapKnf (0.00s)
build_pkg_test.go:96: want hash: 95389ba9b38e9a76b66789217a178e75; got: b2173e707f1f5900e196e6b4db2de4f6
--- FAIL: TestPackOpenLdapNested (0.00s)
build_pkg_test.go:96: want hash: 5c2c2e459d0997fbef089[49](https://github.com/martel-innovate/osmops/runs/7957977761?check_suite_focus=true#step:7:50)9a7976812; got: 0f1f6290a11dc100b3fa4[50](https://github.com/martel-innovate/osmops/runs/7957977761?check_suite_focus=true#step:7:51)130d59372
FAIL
coverage: 100.0% of statements
FAIL github.com/martel-innovate/osmops/osmops/pkgr 0.012s
ok github.com/martel-innovate/osmops/osmops/util 0.003s coverage: 100.0% of statements
ok github.com/martel-innovate/osmops/osmops/util/bytez 0.005s coverage: 100.0% of statements
ok github.com/martel-innovate/osmops/osmops/util/file 0.017s coverage: 98.4% of statements
ok github.com/martel-innovate/osmops/osmops/util/http 0.006s coverage: 100.0% of statements
ok github.com/martel-innovate/osmops/osmops/util/http/sec 0.007s coverage: 100.0% of statements
ok github.com/martel-innovate/osmops/osmops/util/tgz 0.017s coverage: 100.0% of statements
FAIL
The text was updated successfully, but these errors were encountered:
At the moment, the test task of the GitHub CI workflow errors out on the package hash tests. Find out why exactly and fix the tests accordingly.
Details
I thought the reason for that was that after checking out the repo on a Linux box (during the CI workflow) the timestamps of the files we package up in the tests would be different each time, so the package hash would be too. That is, even if the files that make up the package are always the same, their mod/change/access time can be different at different times. Besides a fresh check out, this could also happen e.g. when merging a branch, opening one of the files locally, etc.
So I've implemented a fix to try making reproducible package hashes in our test cases by setting the mod/change/access time to the epoch's start. (That obviously entailed making the tgz lib more flexible to cater for that.) The approach/fix works fine on my macOS box (TM) but for some obscure reason it breaks on the Linux CI's.
Failed test run output
The text was updated successfully, but these errors were encountered: