ci: validate docker config templates against toml examples

[lucasbalieiro]

closes #137

This adds a GitHub Actions workflow and validation script that compares TOML config examples against their corresponding Docker template files.

The check ensures all config keys stay in sync, preventing silent drift between example configs and Dockerized deployments.

This CI does not check the docker_env.example file, because the decision to override values via docker_env or rely on the default configuration is intentionally left to the implementer.

Additionally, docker-release.yml was updated to build and publish the main Docker tag on every PR merged intomain branch.

[lucasbalieiro]

Tested this script on @GitGab19 PR #129 , and the script was able to identify the missing config:

[GitGab19]

Which commit did you use in your test?

Because yesterday I pushed fd245fc which added the new config to the docker templates..

[lucasbalieiro]

Which commit did you use in your test?

Because yesterday I pushed fd245fc which added the new config to the docker templates..

Yeah, I saw it.

I Just reverted it locally, to see if the script would catch the problem and then reapplied to see if the script stop complaining with the fix from the commit

[lucasbalieiro]

ready for review again.

added two new commits:

• 19214e0
  Updates docker-release.yml to run not only when a release is published, but also on every PR merged into main.
  As a result, the latest Docker tag now always reflects the current state of main, while versioned tags (e.g. v0.1.0) remain unchanged and are still published only on releases.

• 0d70601
  Updates docker-compose.yml to reference the latest tags instead of the latest release tags.

[lucasbalieiro]

This is where the “maintainer’s job” that I mentioned in the issue comes into play: when cutting a release, maintainers must update this Docker tag to reference the exact release version being published, ensuring the release points to a stable, immutable image.

[GitGab19]

I guess we can do that by adding one single commit directly to the release branch.

Now we are creating the release branch after we push the release, but we should simply switch the order:

• we create release branch
• we add a new commit where we make docker-compose point to the release image
• we add a new commit where we make stratum-apps and bitcoin_core_sv2 fetch stratum-core from crates.io (as planned here)
• we trigger the release, referencing the release branch instead of main

In this way we would avoid adding commits on main which would need to be reverted right after the release.

Wdyt @plebhash ?

[plebhash]

took note here: #175