Let fetch-mr-plan read GITLAB_TOFU_MR_PLAN_TOKEN and document it for MR comments

What does this MR do?

Closes #206

Since !440 (merged) the README lists GITLAB_TOFU_TOKEN as deprecated in favor of GITLAB_TOFU_MR_PLAN_TOKEN and describes GITLAB_TOFU_MR_PLAN_TOKEN as the token that fetches the merge request plan, but only gitlab-tofu-ctl mr-commenter reads it. gitlab-tofu fetch-mr-plan still reads GITLAB_TOFU_TOKEN alone, so a pipeline that follows the deprecation cannot fetch the plan. As suggested on the issue, I renamed the variable the script reads, to the name the README already gives it, rather than dropping the deprecation.

The MR has two commits, and each passes the checks on its own:

  1. fetch-mr-plan reads GITLAB_TOFU_MR_PLAN_TOKEN and falls back to GITLAB_TOFU_TOKEN, the same way mr-commenter does, so existing pipelines keep working, and its error names both variables as the commenter's does. The token is resolved inside fetch_mr_plan and not with the other variables at the top of the script, since GITLAB_TOFU_DEBUG traces those assignments for every command. The fetch-mr-plan prerequisites name the variable, and three new bats tests cover the missing token, the new variable winning over the old one, and the fallback.
  2. Documentation only: the GITLAB_TOFU_MR_PLAN_TOKEN entry now also names the comments of post_mr_plan_comment and post_mr_comment, with the api scope and Reporter role they need, the two README sections on those comments ask for it instead of GITLAB_TOFU_TOKEN, and the GITLAB_TOFU_TOKEN entry says that it stands in for GITLAB_TOFU_MR_PLAN_TOKEN.

A pipeline that sets both variables now fetches the plan with GITLAB_TOFU_MR_PLAN_TOKEN, so that token needs the read_api scope and developer role the README already asked of it. Like mr-commenter, the script prints nothing when it falls back to GITLAB_TOFU_TOKEN; I can add a warning to both, as the script does for GITLAB_TOFU_VAR_FILE, if you want one.

Tests and checks

I ran tests/unit/gitlab-tofu.bats in the published gitlab-opentofu:4.9.0-opentofu1.12.6-alpine and -debian images with the script under test mounted over /usr/bin/gitlab-tofu, bats from the distribution and bats-support v0.3.0 and bats-assert v2.1.0 as tests/unit.gitlab-ci.yml installs them. A local HTTP server answered the teardown's state DELETE. The two new tests that check the header put a curl stub first on PATH that records its arguments and fails, so none of the new tests needs an API.

New tests against the script on main (busybox sh on Alpine, dash on Debian, same result on both):

not ok 1 gitlab-tofu fetch-mr-plan without a token
#   ERROR: GITLAB_TOFU_TOKEN is not set. This is required to fetch the merge request plan.
not ok 2 gitlab-tofu fetch-mr-plan authenticates with GITLAB_TOFU_MR_PLAN_TOKEN
# line : PRIVATE-TOKEN: mr-plan-token
#   PRIVATE-TOKEN: deprecated-token
ok 3 gitlab-tofu fetch-mr-plan falls back to the deprecated GITLAB_TOFU_TOKEN

With each of the two commits, on both images, the new tests and the other two that need no GitLab-managed state:

ok 1 gitlab-tofu output-dotenv without a dotenv file
ok 2 gitlab-tofu detect-drift with no argument
ok 3 gitlab-tofu fetch-mr-plan without a token
ok 4 gitlab-tofu fetch-mr-plan authenticates with GITLAB_TOFU_MR_PLAN_TOKEN
ok 5 gitlab-tofu fetch-mr-plan falls back to the deprecated GITLAB_TOFU_TOKEN
  • The source tests pass under bash, zsh and ksh on both images (8 of 8 each), at each commit.
  • shellcheck v0.11.0 (koalaman/shellcheck-alpine:v0.11.0) reports nothing for src/gitlab-tofu.sh and .gitlab/scripts/*.sh.
  • make docs in alpine:3.24.1, as check-readme runs it, leaves the tree unchanged at each commit.
  • With GITLAB_TOFU_DEBUG=true and GITLAB_TOFU_MR_PLAN_TOKEN set, gitlab-tofu version prints no token in its trace.

The other unit-test:gitlab-tofu cases need a GitLab-managed state, so I left them to the pipeline; this MR does not change the code they run.

Merge request reports

Loading
Loading