Various AI inspired code changes (And MOAR TESTS)

[PromoFaux]

Summary

A handful of code quality and robustness improvements identified during a review of the codebase following the BATS test suite migration.

• Log error if crontab install fails — start_cron() was calling /usr/bin/crontab without checking the return code. A malformed crontab would silently fail, leaving gravity updates and the update checker permanently disabled with no indication in the logs.

• Expand BATS test coverage — adds two previously untested areas:

  • ADDITIONAL_PACKAGES: a third shared container is started with ADDITIONAL_PACKAGES=wget and a test verifies the package is installed
  • TAIL_FTL_LOG=0: an inline container test verifies that setting TAIL_FTL_LOG=0 suppresses FTL log output and emits the expected notice (the default enabled path is already exercised implicitly by CONTAINER_DEFAULT)

• Replace eval with a bash array in build.sh — the previous approach built a command string and called eval, which is harder to reason about and requires careful quoting. Replacing it with a proper bash array makes argument handling explicit and removes the fragile string substitution used to toggle --no-cache and the tag value.

Test plan

• All existing BATS tests pass across all platforms
• New ADDITIONAL_PACKAGES test passes
• New TAIL_FTL_LOG=0 test passes

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits.

---

• I have read the above and my PR is ready for review.

🤖 Generated with Claude Code

[yubiuser]

Fix contradictory .editorconfig indent settings — indent_style = space requires indent_size to be a number; was incorrectly set to tab. Changed to 4 to match the existing tab_width = 4.

This is wrong. tabs is perfectly valid.

https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#indent_size

[yubiuser]

Replace eval with bash array in build.sh — the previous approach built a command string and passed it to eval, which is vulnerable to shell injection if branch names or fork names contain metacharacters.

This is certainly correct, but what is the attack vector here? Someone tricking themselves into a shell injection?

[PromoFaux]

(Note: this PR was largely written by Claude — responding here on its behalf)

Fair point on both counts.

The editorconfig change has already been dropped — that was simply incorrect on my part.

On the eval comment: you're right, "shell injection" was an overstatement for a local developer tool where the only person supplying input is the developer themselves. The commit message has been updated to describe it more honestly — it's a code quality preference (explicit array vs. opaque string + eval) rather than a security fix.

[yubiuser]

I think we could improve the overall test logic and readability. Currently, we have 3 "default" container (setup in run.sh) we use in different test, but some test require custom container which we setup when needed (FTL shuts down cleanly, tail log is disabled). But we don't re-use functions from run.sh to start/remove custom contains in test_suite.bats. I suggest to not create any container in run.sh but use the functions from it to create all the containers we need inside test_suite.bats. First we could create the 'default' container, run the test for that, then remove it, then create the container with custom settings, run the appropiate test, then stop the container,... and so on.
This would not scatter various contains between those two files.

[PromoFaux]

@yubiuser - see latest commit, I actually pared it down quite a lot from what it was originally suggesting - it wanting 7 different BATS files with various container scenarios.

These two container scenarios cover all use cases we have in the tests currently and there is no need to start a fresh container for every single test.

Does that make it easier to follow?