- Rename all 'minio server' references to './buckit server'
- Update default credentials from minioadmin to buckitadmin
- Add 'pkill -9 buckit' to all test cleanup functions
- Pin workflow Go version to 1.25.10
- Update vulnerable Go modules
- Fix resiliency tests: restore docker compose --wait, add
MC_HOST_local env var, fix induce_bitrot_for_xlmeta typo
- Update mint docker-compose images to buckit
- Update IAM integration and root lockdown test scripts
on unversioned buckets its possible that 0-byte objects
might lose quorum on flaky systems, allow them to be same
as DELETE markers. Since practically speak they have no
content.
On occasion this test fails:
```
2022-09-12T17:22:44.6562737Z === RUN TestGetObjectWithOutdatedDisks
2022-09-12T17:22:44.6563751Z erasure-object_test.go:1214: Test 2: Expected data to have md5sum = `c946b71bb69c07daf25470742c967e7c`, found `7d16d23f07072af1a809707ba101ae07`
2
```
Theory: Both objects are written with the same timestamp due to lower timer resolution on Windows. This results in secondary resolution, which is deterministic, but random.
Solution: Instead of hacking in a wait we request the specific version we want. Should still keep the test relevant.
Bonus: Remote action dependency for vulncheck
abuckit