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
{{ message }}
Repository navigation
Automate Cloudflare provider updates with a tool that supports OpenTofu lock files #3
This repository pins the Cloudflare provider exactly (= 5.24.0 in versions.tf), and .terraform.lock.hcl records it under the OpenTofu registry (registry.opentofu.org/cloudflare/cloudflare). CI runs OpenTofu 1.12.
Dependabot is being added for GitHub Actions in #2, but not for the provider. Dependabot has no OpenTofu ecosystem of its own; OpenTofu goes through the terraform ecosystem, which is documented as working only up to OpenTofu 1.7. There is also an open upstream report of lock-file updates failing under OpenTofu. Turning it on here would most likely fail, or rewrite the lock under a different registry host, which would break tofu init in CI.
Who is affected and why it matters
This is the provider that manages production DNS, R2 buckets and service tokens. An exact pin that nothing ever proposes updating falls behind without anyone noticing, including on security fixes.
Expected behaviour
Provider updates are proposed automatically, and each proposal keeps a valid OpenTofu lock file that passes scripts/test.sh.
Acceptance criteria
Pick a mechanism that supports OpenTofu lock files, or confirm that Dependabot's terraform ecosystem now handles this setup. Record the evidence either way.
A first provider-update PR is opened by that mechanism, with a lock file that passes CI.
Nothing bypasses the repository's non-destructive plan check (scripts/assert-no-destructive-plan.sh).
PR #8 configures Renovate for the OpenTofu registry, exact provider pins, and lock-file maintenance. Renovate documentation explicitly supports OpenTofu lock files: https://docs.renovatebot.com/modules/manager/terraform/ . The supported-runtime configuration validation, credential-free provider-discovery evaluation, and complete repository validation passed. CodeRabbit completed a finding-free review at the signed PR head.
The PR remains gated on required CI, currently affected by GitHub Actions job delays. This does not complete the final acceptance criterion: an actual automation-authored provider-update PR must have a valid generated lock file and passing CI.
Blocker: Repository coverage by the existing selected-repository Renovate installation is unverified. GitHub requires maintainer reauthentication to inspect it; the maintainer has been asked in the interactive session to confirm this repository is included. No app permissions, production access, or apply controls have been changed.
The configuration was delivered by PR #8, merged at 2026-10-01 18:11:36 UTC as 889d3b905f454895b6d707234e8c1e18aeb94a6c. Required current-head CI, complete thread clearance, signed-commit verification and a substantive CodeRabbit review all passed before the exact-head squash merge.
This issue remains open for its final acceptance criterion: verify the first automation-authored provider-update PR and generated lock file against CI. Installation coverage is still unverified; the existing maintainer reauthentication request remains the named blocker. No live infrastructure was applied by this change.
PR #8 is merged at 889d3b905f454895b6d707234e8c1e18aeb94a6c. Its main-branch CI passed after merge. The repository now configures exact provider updates through the OpenTofu registry and lock-file maintenance; local validation and a credential-free Renovate evaluation passed before merge.
The end-to-end automation acceptance remains outstanding: a bounded current read shows no open automation-authored provider update PR, and the app's coverage of this repository remains unverified. This issue stays open until the first real provider-update PR regenerates a valid lock file and passes required CI. No live resource import or apply was performed.
Checked the last open criterion on 2026-10-10: not met, and waiting will not meet it.
Nine days after #8 merged, the updater it configured has produced nothing here:
No pull request from Renovate in any state. Every pull request in this repository is from Dependabot (GitHub Actions only) or the engineer.
No dashboard issue, open or closed. renovate.json keeps the default dashboard setting, which opens one on the first run whether or not an update exists. So its absence means Renovate has never run here, not that the provider is current.
No check suite from the Renovate app on the current main commit, where a repository it runs in has one.
The organization's Renovate installation covers selected repositories only, and this repository is not acting like one of them. The same is true of three other repositories; devantler-tech/monorepo#4098 has the full evidence and the options, and now blocks this issue.
Nothing in this repository needs to change for the updater to start, with one exception: before its first run the configuration should turn the dashboard off (devantler-tech/monorepo#2547). That is listed on #4098.
The provider pin is still = 5.24.0. Once Renovate runs here, the remaining check is the one already listed above: its first provider-update pull request keeps a lock file that passes scripts/test.sh, and the non-destructive plan check still applies.
🤖 Generated by the Agentic Engineer (interactive Claude Code session)
The first criterion is met with a different mechanism, and this issue no longer waits on Renovate.
Mechanism (criterion 1): GitHub's Dependabot now has its own opentofu ecosystem. Its documentation says it updates providers in .tf files and refreshes .terraform.lock.hcl when one is present (supported ecosystems). Dependabot already runs here for the workflow actions, so #26 moved provider updates to it, with the same seven-day cooldown the third-party actions use, and removed the Renovate configuration that never ran. It merged as a20597ed503c875805e345f69a9e2f1ce889eb71, and main CI passed.
First run, read just now: Dependabot's opentofu job (run 40166984198) found cloudflare/cloudflare 5.28.0, looked it up on registry.opentofu.org, and held the newer 5.28.1 back because it is still inside the cooldown. So the file is read, and the right registry is used.
Still open (criterion 2): 5.28.1 was published on 2026-10-20 and leaves the cooldown on 2026-10-27, so the first weekly run after that, expected on 2026-11-02, should open the first provider pull request. That pull request has to keep the lock under registry.opentofu.org, with checksums that pass scripts/test.sh. 5.28.1's provider schema is identical to 5.28.0's, so it needs no configuration change.
Criterion 3: the non-destructive plan check is untouched; the update path has no credentials and no apply step.
This issue therefore no longer depends on devantler-tech/monorepo#4098, which is about giving the Renovate app access. I have removed that blocking link, because this repository no longer carries a Renovate configuration.
Activity
ci: propose GitHub Actions updates automatically (#4)
chore: agent-claim #3 nonce=93647e4519278d9a78267c1d6e91b7b6
devantler commentedon Oct 1, 2026
PR #8 configures Renovate for the OpenTofu registry, exact provider pins, and lock-file maintenance. Renovate documentation explicitly supports OpenTofu lock files: https://docs.renovatebot.com/modules/manager/terraform/ . The supported-runtime configuration validation, credential-free provider-discovery evaluation, and complete repository validation passed. CodeRabbit completed a finding-free review at the signed PR head.
The PR remains gated on required CI, currently affected by GitHub Actions job delays. This does not complete the final acceptance criterion: an actual automation-authored provider-update PR must have a valid generated lock file and passing CI.
Blocker: Repository coverage by the existing selected-repository Renovate installation is unverified. GitHub requires maintainer reauthentication to inspect it; the maintainer has been asked in the interactive session to confirm this repository is included. No app permissions, production access, or apply controls have been changed.
devantler commentedon Oct 1, 2026
The configuration was delivered by PR #8, merged at 2026-10-01 18:11:36 UTC as
889d3b905f454895b6d707234e8c1e18aeb94a6c. Required current-head CI, complete thread clearance, signed-commit verification and a substantive CodeRabbit review all passed before the exact-head squash merge.This issue remains open for its final acceptance criterion: verify the first automation-authored provider-update PR and generated lock file against CI. Installation coverage is still unverified; the existing maintainer reauthentication request remains the named blocker. No live infrastructure was applied by this change.
devantler commentedon Oct 1, 2026
PR #8 is merged at
889d3b905f454895b6d707234e8c1e18aeb94a6c. Its main-branch CI passed after merge. The repository now configures exact provider updates through the OpenTofu registry and lock-file maintenance; local validation and a credential-free Renovate evaluation passed before merge.The end-to-end automation acceptance remains outstanding: a bounded current read shows no open automation-authored provider update PR, and the app's coverage of this repository remains unverified. This issue stays open until the first real provider-update PR regenerates a valid lock file and passes required CI. No live resource import or apply was performed.
devantler commentedon Oct 10, 2026
Checked the last open criterion on 2026-10-10: not met, and waiting will not meet it.
Nine days after #8 merged, the updater it configured has produced nothing here:
renovate.jsonkeeps the default dashboard setting, which opens one on the first run whether or not an update exists. So its absence means Renovate has never run here, not that the provider is current.maincommit, where a repository it runs in has one.The organization's Renovate installation covers selected repositories only, and this repository is not acting like one of them. The same is true of three other repositories; devantler-tech/monorepo#4098 has the full evidence and the options, and now blocks this issue.
Nothing in this repository needs to change for the updater to start, with one exception: before its first run the configuration should turn the dashboard off (devantler-tech/monorepo#2547). That is listed on #4098.
The provider pin is still
= 5.24.0. Once Renovate runs here, the remaining check is the one already listed above: its first provider-update pull request keeps a lock file that passesscripts/test.sh, and the non-destructive plan check still applies.chore(renovate): turn the dependency dashboard off before the first r…
chore: agent-claim #3 nonce=5b530ced3f419e5e13c7f3393c3e1be0
chore(deps): propose Cloudflare provider updates with Dependabot (#26)
devantler commentedon Oct 25, 2026
The first criterion is met with a different mechanism, and this issue no longer waits on Renovate.
opentofuecosystem. Its documentation says it updates providers in.tffiles and refreshes.terraform.lock.hclwhen one is present (supported ecosystems). Dependabot already runs here for the workflow actions, so #26 moved provider updates to it, with the same seven-day cooldown the third-party actions use, and removed the Renovate configuration that never ran. It merged asa20597ed503c875805e345f69a9e2f1ce889eb71, andmainCI passed.opentofujob (run 40166984198) foundcloudflare/cloudflare 5.28.0, looked it up onregistry.opentofu.org, and held the newer 5.28.1 back because it is still inside the cooldown. So the file is read, and the right registry is used.registry.opentofu.org, with checksums that passscripts/test.sh. 5.28.1's provider schema is identical to 5.28.0's, so it needs no configuration change.This issue therefore no longer depends on devantler-tech/monorepo#4098, which is about giving the Renovate app access. I have removed that blocking link, because this repository no longer carries a Renovate configuration.