Three scenarios running the compiled daemon with a real INI config:

- TestE2E_LocalJob_RunsOnSchedule: a @every 1s local job must write a
  distinct marker to disk. Asserts on the file-system side-effect rather
  than just stdout to prove the spawned process actually executed (not
  just that ofelia logged an "execution" event).

- TestE2E_LocalJob_RunOnStartup: run-on-startup=true must fire at boot
  even when the cron (0 0 1 1 *) would never trigger within the test
  window — isolates the startup-trigger code path.

- TestE2E_LocalJob_SurvivesMultipleExecutions: sanity-check that the
  scheduler keeps ticking across ~6 consecutive runs and still accepts
  SIGTERM afterwards. Regression guard against goroutine leaks or
  scheduling-drift hangs.

All three use t.TempDir() + t.Parallel() and rely exclusively on the
harness added in the prior commit.

Signed-off-by: Sebastian Mendel <[email protected]>

Two scenarios that exercise the full Docker path (unlike the existing
e2e tests which stub the provider):

- TestE2E_DockerRunJob_SpawnsContainer: runs `echo OFELIA_E2E_DOCKER_MARKER`
  inside alpine:3.20 via job-run, forces `delete = false` so the container
  survives long enough to inspect, then uses `docker logs` to verify the
  marker reached the container and came back through ofelia's stdout
  forwarder.

- TestE2E_DockerRunJob_FailingContainerMarkedFailed: a container that
  exits 42 must be surfaced as `failed: true` in ofelia's log. Regression
  guard so broken cron jobs never look healthy.

Both tests skip cleanly via `dockerAvailable()` when the docker daemon
is unreachable, pre-pull alpine:3.20 to avoid registry-latency races,
and use timestamped container names so parallel runs can't collide.

Signed-off-by: Sebastian Mendel <[email protected]>

Three scenarios for the `ofelia validate` subcommand:

- TestE2E_Validate_MalformedINI: unterminated section ⇒ the user must
  see the `unclosed section` detail and the `INI syntax` hint.
- TestE2E_Validate_MissingConfigFile: missing path ⇒ the error must
  include the path and the `no such file or directory` cause.
- TestE2E_Validate_AcceptsValidConfig: a well-formed config containing
  both job-local and job-run must produce a JSON dump that lists both
  jobs and their image.

The tests intentionally do not assert on the exit code because
ofelia.go documents exiting gracefully (exit 0) on argument errors;
they check the human-readable stderr/stdout instead — which is what
an operator debugging a failing deploy actually reads.

Signed-off-by: Sebastian Mendel <[email protected]>

…emon

Two scenarios exercising the full shutdown path end-to-end:

- TestE2E_GracefulShutdown_SIGTERM sends SIGTERM after at least one job
  has run, then asserts the daemon exits within 10s, emits the
  'Received shutdown signal' and 'graceful shutdown' banners, and
  leaves exit code 0. Exercises ShutdownManager → GracefulScheduler →
  main-loop `<-c.done` rendezvous via signal, which cannot be tested
  in-process because Go's signal delivery is per-PID.

- TestE2E_GracefulShutdown_SIGINT covers the Ctrl+C signal path
  independently, since ShutdownManager registers SIGINT and SIGTERM
  separately.

These complement the existing in-process scheduler lifecycle tests in
e2e/scheduler_lifecycle_test.go (kept untouched).

Signed-off-by: Sebastian Mendel <[email protected]>

…ut-of-scope items

Rewrite e2e/README.md so new contributors understand:
- What distinguishes e2e tests from the existing integration tests
  (build real binary vs. in-process Docker stub).
- How to run the suite locally (go test -tags=e2e -race ./e2e/...).
- Which scenarios are covered per-file.
- Which job types are deliberately out of scope (job-compose, Swarm
  job-service-run, web UI auth, SIGHUP reload) so reviewers don't
  conflate e2e with a fix-all target.
- How the helpers in helpers_test.go fit together.

Signed-off-by: Sebastian Mendel <[email protected]>

Flip `enable-e2e-tests: true` on the reusable go-check workflow caller
and pin `e2e-test-packages: ./e2e/...` so the dedicated E2E Tests job
runs on every PR, push to main, merge-group and weekly cron. Coverage
is uploaded under the `e2e` Codecov flag.

The e2e tests build the real ofelia binary and spawn it with Docker
on ubuntu-latest runners; see e2e/README.md for the list of scenarios.
They are independent of the existing integration tests (-tags=integration)
which remain in-process and continue to run in the Integration Tests job.

Update .github/template.yaml's intentional-drift entry so the
check-template-drift.yml workflow keeps accepting ci.yml's deviation
from the go-app template — now documented to cover both
`enable-integration-tests: true` and `enable-e2e-tests: true`.

Signed-off-by: Sebastian Mendel <[email protected]>