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
The following three tracked files are regenerated by Alire on every test-crate build and drift per host, repeatedly dirtying the working tree and interrupting release cleanup operations:
`test/config/clara_tests_config.ads`
`test/config/clara_tests_config.gpr`
`test/config/clara_tests_config.h`
Evidence
Observed during the clara PR #14 (v1.0.0 → v1.0.1) cleanup gate on 2026-06-09. After running the in-container PR #14 build validation (`alr build -- -XGNATCOLL_ICONV_OPT=` in `dev-container-ada-system-1`), the working tree showed:
The macOS host carries the macos/x86_64/homebrew triple; the dev container's aarch64 Ubuntu carries linux/aarch64/ubuntu. Every cross-host build flips these. Note: the `Alire_Host_Arch` value tracked on `main` (`x86_64`) does not match this MacBook (arm64) either, suggesting the baseline was committed from a different host than the current dev environment.
2. Tracked-baseline content drift: the tracked `clara_tests_config.h` on `main` still carries leftover `functional_tests` content (the template clara was cloned from) and the stale `CRATE_VERSION "3.0.0"`:
```diff
-/* Configuration for functional_tests generated by Alire /
-#ifndef FUNCTIONAL_TESTS_CONFIG_H
-#define FUNCTIONAL_TESTS_CONFIG_H
-#define CRATE_VERSION "3.0.0"
-#define CRATE_NAME "functional_tests"
+/ Configuration for clara_tests generated by Alire */
+#ifndef CLARA_TESTS_CONFIG_H
+#define CLARA_TESTS_CONFIG_H
+#define CRATE_VERSION "1.0.1"
+#define CRATE_NAME "clara_tests"
```
The `.ads` and `.gpr` files carry the same stale `Crate_Version := "3.0.0"` on `main`. So the regenerated files are arguably more correct than the tracked baseline (they fix the `functional_tests` leftover and bump `Crate_Version` to match `test/alire.toml` version 1.0.1) but also carry the host-triple flip.
Why this matters
Release-cleanup discipline is interrupted: PR chore(release): bump version 1.0.0 -> 1.0.1 (first Alire-published release) #14 (v1.0.1 version bump) cleanup required `git restore` of these files before `git switch main` could be performed cleanly. This is a recurring tax on every release operation that crosses build hosts.
The tracked baseline is wrong: at minimum, the `functional_tests` leftover content in `.h` and the stale `CRATE_VERSION "3.0.0"` (vs the actual `test/alire.toml` version `1.0.1`) should not be on `main`.
This investigation can land on a separate branch after v1.0.1 ships.
Possible directions (for the investigator, not a decision here)
Add `test/config/clara_tests_config.{ads,gpr,h}` to `.gitignore` and remove them from tracking, since Alire regenerates them on every build. Most similar Alire crates do not track these files. (`functional` may or may not — worth comparing.)
Keep them tracked but normalize the host triple to a stable value (e.g., regenerate from a canonical CI host and re-baseline) so the on-`main` content is what every build host writes — at the cost of needing a re-baseline whenever Alire's generation logic changes.
Investigate why the tracked `.h` carries `functional_tests` content — likely a copy-paste from the functional template at clara's inception, never corrected.
Companion saved memory: `feedback_test_config_files_host_specific` (Alire-generated test/config files flip between linux/ubuntu and macos/homebrew per host; revert before staging or they churn forever).
Summary
The following three tracked files are regenerated by Alire on every test-crate build and drift per host, repeatedly dirtying the working tree and interrupting release cleanup operations:
Evidence
Observed during the clara PR #14 (v1.0.0 → v1.0.1) cleanup gate on 2026-06-09. After running the in-container PR #14 build validation (`alr build -- -XGNATCOLL_ICONV_OPT=` in `dev-container-ada-system-1`), the working tree showed:
```
modified: test/config/clara_tests_config.ads
modified: test/config/clara_tests_config.gpr
modified: test/config/clara_tests_config.h
```
The diff content showed two distinct kinds of drift:
1. Host triple flip (Alire's regeneration writes the build host's identity):
```diff
```
The macOS host carries the macos/x86_64/homebrew triple; the dev container's aarch64 Ubuntu carries linux/aarch64/ubuntu. Every cross-host build flips these. Note: the `Alire_Host_Arch` value tracked on `main` (`x86_64`) does not match this MacBook (arm64) either, suggesting the baseline was committed from a different host than the current dev environment.
2. Tracked-baseline content drift: the tracked `clara_tests_config.h` on `main` still carries leftover `functional_tests` content (the template clara was cloned from) and the stale `CRATE_VERSION "3.0.0"`:
```diff
-/* Configuration for functional_tests generated by Alire /
-#ifndef FUNCTIONAL_TESTS_CONFIG_H
-#define FUNCTIONAL_TESTS_CONFIG_H
-#define CRATE_VERSION "3.0.0"
-#define CRATE_NAME "functional_tests"
+/ Configuration for clara_tests generated by Alire */
+#ifndef CLARA_TESTS_CONFIG_H
+#define CLARA_TESTS_CONFIG_H
+#define CRATE_VERSION "1.0.1"
+#define CRATE_NAME "clara_tests"
```
The `.ads` and `.gpr` files carry the same stale `Crate_Version := "3.0.0"` on `main`. So the regenerated files are arguably more correct than the tracked baseline (they fix the `functional_tests` leftover and bump `Crate_Version` to match `test/alire.toml` version 1.0.1) but also carry the host-triple flip.
Why this matters
Out of scope
Possible directions (for the investigator, not a decision here)
Reference
Refs: adafmt#42