Skip to content

deps: update setup-ok tool versions - #186

Open
kjoremiljo-renovate[bot] wants to merge 1 commit into
mainfrom
ok-renovate/setup-ok-tool-versions
Open

deps: update setup-ok tool versions#186
kjoremiljo-renovate[bot] wants to merge 1 commit into
mainfrom
ok-renovate/setup-ok-tool-versions

Conversation

@kjoremiljo-renovate

@kjoremiljo-renovate kjoremiljo-renovate Bot commented Jan 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Update Change Pending
gruntwork-io/boilerplate minor v0.10.1 → v0.16.0
gruntwork-io/terragrunt major v0.96.1 → v1.1.2
hashicorp/terraform minor 1.14.3 → 1.15.8
mikefarah/yq minor v4.50.1 → v4.53.3
oslokommune/ok minor v5.15.3 → v5.20.1 v5.21.0 (+1)
warrensbox/terraform-switcher minor v1.13.0 → v1.19.0

Release Notes

gruntwork-io/boilerplate (gruntwork-io/boilerplate)

v0.16.0

Compare Source

What's Changed

New Contributors

Full Changelog: gruntwork-io/boilerplate@v0.15.0...v0.16.0

v0.15.0

Compare Source

🐛 Bug Fixes

Handling ancestor dependencies

Added support for recursive dependencies to the manifest to ensure that nested and ancestor dependencies are properly processed and resolved. Additional testing has also been included to verify this behavior.

Note that although this isn't a breaking change, this does require an update to the manifest schema, and as such you'll want to ensure that your manifest parsing isn't impacted. Due to the fact that a field has only been added, this risk is minimal if you use a modern YAML/JSON parser.

What's Changed

Full Changelog: gruntwork-io/boilerplate@v0.14.0...v0.15.0

v0.14.0

Compare Source

🛠️ Breaking Changes

Dependencies Now Generate Concurrently

Dependencies in templates now generate concurrently by default, with the option to run sequentially or with different concurrency limits using the --parallelism flag.

This will be a breaking change for any templates that relied on dependencies generating in the exact order in which they are defined in templates (e.g. if multiple dependencies generate the same file, expecting later dependencies to overwrite earlier ones).

For more information read the for_each documentation.

What's Changed

Full Changelog: gruntwork-io/boilerplate@v0.13.0...v0.14.0

v0.13.0

Compare Source

✨ New Features

Manifest File Generation

Boilerplate can now produce a manifest file that records every file generated during a run, along with SHA256 checksums. Enable it with the new --manifest flag:

boilerplate \
    --template-url ./templates/service \
    --output-folder ./output \
    --non-interactive \
    --manifest

This creates a boilerplate-manifest.yaml in the output directory containing:

  • File inventory — every generated file with its relative path and sha256: checksum
  • Source checksum — a checksum of the template source (git commit SHA or directory hash)
  • Variables & dependencies — the resolved variable values and dependency tree used during the run
  • Schema version — a URL pointing to a published https://boilerplate.gruntwork.io/schemas/manifest/v1/schema.json for easy validation

The manifest format is auto-detected from the file extension: .json produces JSON, everything else produces YAML. To write to a custom path, use --manifest-file:

boilerplate \
    --template-url ./templates/service \
    --output-folder ./output \
    --non-interactive \
    --manifest-file ./reports/manifest.json

This is useful for auditing which files came from a template, drift detection by comparing checksums after the fact, and CI/CD pipelines that need to programmatically consume the list of generated files in downstream steps.

See https://boilerplate.gruntwork.io/advanced/manifest/ for details.

Exported validation Package

The validation package is now exported directly, so consumers of Boilerplate as a library can import validation instead of relying on the re-export through the variables package.

📖 Documentation Updates

  • Added a docs homepage, Windows support page, and terminology page
  • Fixed miscellaneous docs bugs

🧹 Chores

  • Removed CircleCI configuration
  • Fixed tests to avoid relying on the current branch existing in the remote

What's Changed

Full Changelog: gruntwork-io/boilerplate@v0.12.1...v0.13.0

v0.12.1

Compare Source

What's Changed

Full Changelog: gruntwork-io/boilerplate@v0.12.0...v0.12.1

v0.12.0

Compare Source

🛠️ Breaking Changes

Default variables no longer prompt for values by default in interactive mode

Variables with default values no longer prompt users for interactive input unless using the new confirm attribute.

variables:
  - name: AppName
    type: string
    default: "my-app"
    confirm: true  # User will be prompted, with "my-app" as the default

  - name: ContainerName
    type: string
    default: "container"
    # No confirm — silently uses the computed default

This ensures that dynamically determined values for variables won't cause errors during interactive generation and reduces the number of prompts users encounter while generating from a template interactively.

Validation length uses functional form now

The length validation now uses the functional form length(min, max) instead of the previous length-min-max form.

All validations with parameters will use this functional form going forward.

✨ New Features

New validation type regex(pattern) supported.

The validation type regex(pattern) is now supported to validate variable values against regex patterns.

e.g.

- name: SlugName
  type: string
  description: URL-friendly project slug
  validations:
    - required
    - length(3, 30)
    - regex("^[a-z0-9-]+$")

⚙️ Process Updates

WASM build target added

Releases now support JavaScript runtimes through compiled WASM build targets.

📖 Documentation Updates

Boilerplate website created

Boilerplate now has a dedicated website at https://boilerplate.gruntwork.io to document the behavior of Boilerplate.

What's Changed

Full Changelog: gruntwork-io/boilerplate@v0.11.1...v0.12.0

v0.11.1

Compare Source

What's Changed

Full Changelog: gruntwork-io/boilerplate@v0.11.0...v0.11.1

v0.11.0

Compare Source

❌ No Release Assets

Use release v0.11.1 instead which fixes the deploy pipeline to create release assets.

🛠️ Breaking Changes

ProcessTemplate and ProcessTemplateWithContext now take variables.Dependency as a pointer.

What's Changed

New Contributors

Full Changelog: gruntwork-io/boilerplate@v0.10.1...v0.11.0

gruntwork-io/terragrunt (gruntwork-io/terragrunt)

v1.1.2

Compare Source

✨ New Features

Scaffold straight from the catalog README view with ctrl+d

In the terragrunt catalog TUI, pressing ctrl+d while reading a component's README now scaffolds it immediately, skipping the interactive form. Module and template inputs are written as # TODO placeholders, and unit/stack copies get a fully placeholder terragrunt.values.hcl. The hint bar at the bottom of the README view advertises the new key.

🏎️ Performance Improvements

Fewer filesystem checks when resolving find_in_parent_folders()

626834110-d04de8b8-cc1b-4426-ab1f-d1760601dd12

find_in_parent_folders() walks up from a unit toward the filesystem root, checking each directory for the configuration file it was asked to find. Even when the call named a file, as in find_in_parent_folders("root.hcl"), each directory along the way was also checked for the default configuration filenames. Units sharing a parent chain then repeated every check their siblings had already made.

Terragrunt now checks only the filename the call names, and reuses what it already learned about a directory for the rest of the command. Deeply nested estates benefit most, since every level between a unit and its root configuration used to be re-checked once per unit.

In micro-benchmarks, resolving the root configuration for 100 units nested eight directories deep went from 4.8ms to 0.49ms. Across the benchmarked shapes the lookups run between 7x and 10x faster, and the time saved grows with both the number of units and how deeply they sit below their root configuration.

🐛 Bug Fixes

Fixed roles assuming themselves for backend operations

A regression in v1.1.1 broke setups that provide static AWS credentials and configure a role via the iam_role attribute, the --iam-assume-role flag, or TG_IAM_ASSUME_ROLE.

In those setups, Terragrunt assumes the role once at the start of a run, and every later AWS call uses that role session. In v1.1.1, backend operations like bootstrapping the state bucket started performing an extra role assumption of their own. Since the run was already using the role session at that point, the role tried to assume itself, and AWS rejected the call with an AccessDenied error unless the role's trust policy happened to include the role itself.

Backend operations now reuse the role session from the start of the run, as they did before v1.1.1.

This does not affect the assume_role attribute of the remote_state block. Roles configured there are backend-specific and are still assumed on top of the supplied credentials, so the cross-account role assumption should continue to work as expected.

Local sources no longer re-init when uncopied files change

For units with a local source, Terragrunt decides whether the cached copy is stale by hashing the source directory. That hash previously covered every file in the directory, including hidden files and exclude_from_copy matches that are never copied into the cache. Creating or touching such a file (an editor swap file, a scratch note) changed the hash, forcing a needless re-copy and auto-init on the next run.

The hash now covers only the files a copy would deliver, honoring the default hidden-file rule along with include_in_copy and exclude_from_copy. Files that never reach the cache no longer trigger re-initialization.

Fixed width truncation of colored and multi-byte log content

The width option in a custom log format sizes a column to a fixed number of visible characters. When the content held color codes or multi-byte characters and was longer than the column, truncation cut the raw bytes: it could slice through the middle of a color code, leaving color bleeding into the rest of the line, or split a multi-byte character into invalid output, and it dropped more visible text than the configured width.

width now measures and cuts by visible characters. Color codes are preserved intact, multi-byte characters are never split, and the column keeps exactly the requested number of visible characters.

Provider cache downloads now require a secret URL

The Provider Cache Server now hardens the download endpoint that fetches provider archives on the caller's behalf. That endpoint attaches whatever registry credentials are configured for the upstream host, and it was the only one on the server that did not require the token generated for the run, so any other process on the machine could use a running cache server to pull artifacts from a private registry with the credentials of whoever started the run.

The download URLs handed to OpenTofu and Terraform now carry a secret path segment, generated fresh each time the cache server starts and redacted from the server's own logs. Requests that omit the segment get a 404.

Run report no longer mangles the names of paths that share a prefix with the working directory

When a run's path shared a string prefix with the working directory without being nested under it, the run report shortened its name by shearing off the prefix mid-segment. A working directory of /repo/project alongside a run at /repo/project-staging/unit produced the name -staging/unit.

The report now shortens a path only when it is genuinely nested under the working directory. Sibling paths keep their full name.

Feature flag defaults no longer leak between units in run --all

A feature block's default was recorded once per run and shared by every unit. During run --all, the first unit to be parsed set the value for a flag name, so a unit defining default = false could evaluate feature.toggle.value as true because a sibling unit was parsed first. Which unit won depended on parsing order, making the result vary between runs.

Defaults are now resolved per unit, including defaults inherited through include. Overrides passed with --feature or TG_FEATURE continue to apply to every unit in the run.

Thanks to @​dhotcolorado for reporting and fixing this!

Fixed S3 source downloads under EKS Pod Identity

Downloading unit sources from private S3 buckets (s3::https://...) now works when EKS Pod Identity is the only credential source. Previously, the bundled aws-sdk-go v1 rejected the Pod Identity Agent endpoint (169.254.170.23) because it only allowed loopback hosts. Terragrunt now uses aws-sdk-go v1.55.6, which allows the EKS and ECS container credential endpoints.

🧪 Experiments Added

otel-logs experiment exports logs to OpenTelemetry

Terragrunt previously emitted only traces and metrics, so there was no way to ship its log output to an OpenTelemetry backend or correlate log lines with the spans of a failed run.

Enable the new otel-logs experiment to add an OpenTelemetry logs signal, configured with TG_TELEMETRY_LOGS_EXPORTER:

  • none - no log exporting, the default.
  • console - write log records to the console as JSON.
  • otlpHttp - export logs to an OpenTelemetry collector over HTTP.
  • otlpGrpc - export logs to an OpenTelemetry collector over gRPC.
TG_TELEMETRY_LOGS_EXPORTER=otlpHttp terragrunt run --all --experiment otel-logs -- apply

The OTLP exporters read the endpoint from the standard OTEL_EXPORTER_OTLP_ENDPOINT environment variable. Set TG_TELEMETRY_LOGS_EXPORTER_INSECURE_ENDPOINT=true to disable TLS when collecting locally. Records emitted while a span is active carry its trace and span IDs, so a failed unit's logs link to its span in the backend. Without the experiment enabled, the logs exporter stays inert regardless of TG_TELEMETRY_LOGS_EXPORTER.

profiling experiment adds pprof collection for Terragrunt runs

Enable the new profiling experiment to collect CPU profiles, memory (heap) profiles, and goroutine profiles (stack traces of all goroutines) using CLI flags. Profiling is intended for debugging the performance of Terragrunt itself, and for exploring ways to optimize Terragrunt as an application; it will not help with improving the performance of the infrastructure Terragrunt manages.

Example:

terragrunt --experiment=profiling --profile-cpu cpu.prof --profile-mem mem.prof --profile-goroutine goroutine.prof run -- plan

Use --profile-dir to collect all profiles into a single directory with conventional names (terragrunt_cpu.prof, terragrunt_mem.prof, terragrunt_goroutine.prof):

terragrunt --experiment=profiling --profile-dir /tmp/profiles run --all -- plan

The same behavior is available via environment variables when the profiling experiment is enabled:

  • TG_PROFILE_CPU
  • TG_PROFILE_MEM
  • TG_PROFILE_GOROUTINE
  • TG_PROFILE_DIR

When using --profile-dir or TG_PROFILE_DIR, Terragrunt also sets TOFU_CPU_PROFILE for each unit so downstream OpenTofu processes (OpenTofu 1.11 or later) write their own CPU profiles into unit-specific subdirectories. An explicitly set TOFU_CPU_PROFILE is never overridden.

🧪 Experiments Updated

azure-backend now manages Azure Storage remote state

The azure-backend experiment now enables functional Terragrunt support for the Azure Storage (azurerm) remote-state backend.

When the experiment is enabled, Terragrunt can bootstrap the resource group, storage account, and blob container used by remote_state { backend = "azurerm" }, detect whether the backend needs bootstrapping, converge blob versioning and soft-delete settings, delete state blobs or containers, and migrate state blobs within the same storage account.

Terragrunt-only settings such as location, the storage account SKU options, the skip_* flags, enable_soft_delete, soft_delete_retention_days, and msi_resource_id are consumed by Terragrunt and removed before it runs OpenTofu/Terraform with init -backend-config, so the underlying azurerm backend receives only keys it understands. msi_resource_id is not bootstrap-only: it also selects the managed identity used for delete and migrate.

This remains opt-in while the experiment is active:

terragrunt --experiment azure-backend run -- plan

Thanks to @​omattsson for driving this support forward.

oci - Credential helpers for OCI module sources

oci:// module downloads now use the Docker credential helpers you already have configured, so registries like Amazon ECR authenticate automatically with no extra setup.

oci - Content-addressable caching for OCI module sources

oci:// module sources now integrate with Content Addressable Storage. When the oci experiment is enabled, downloads are cached by their manifest digest, so a repeated fetch of the same tag or digest is served from the local store instead of re-downloaded from the registry.

Mutable tags stay correct: every fetch re-resolves the tag to its current manifest digest at download time, so re-pushing a module under the same tag invalidates the cache and pulls the new content rather than serving a stale copy. A digest-pinned source (?digest=sha256:...) skips registry resolution and keys the cache directly.

oci - Downloading modules from OCI registries

The oci experiment now downloads source code (including OpenTofu modules) from OCI Distribution registries. When enabled, Terragrunt accepts oci:// source URLs in Terragrunt configurations (including terraform.source attributes). Specify either tag or digest; omitting both selects the latest tag. //subdir selectors are supported. Artifacts follow the same publishing contract OpenTofu 1.10 consumes natively.

Authentication covers static credentials via interim TG_TMP_OCI_* environment variables and read-only ambient discovery of Docker and containers auth files. Static credentials can be limited to one registry with TG_TMP_OCI_REGISTRY; without it, the configured token or username and password may be offered to any registry the process contacts. Credential helpers (such as ecr-login) are not invoked yet, so registries that need per-run token minting only work while an externally obtained login is present in an ambient file.

When the experiment is disabled, oci:// sources remain unsupported.

For setup steps, see the experiment documentation.

Pull Requests

✨ Features
🐛 Bug Fixes
🏎️ Performance
📖 Documentation
🧹 Chores

v1.1.1

Compare Source

🐛 Bug Fixes

Chained role assumption for the S3 backend

When AWS credentials were supplied through --auth-provider-cmd or environment variables, Terragrunt ignored the assume_role attribute of the remote_state block for its own backend operations, such as bootstrapping the state bucket. In cross-account setups this caused access errors, even though OpenTofu/Terraform itself assumed the role correctly during runs.

Terragrunt now uses the supplied credentials as the source identity and assumes the configured role on top of them. The same applies to roles configured via the iam_role attribute or the --iam-assume-role flag, and to fetching dependency outputs directly from S3 state.

Safer temporary clone directories for terragrunt catalog

Terragrunt now creates a fresh temporary clone directory for each catalog load, rejects symlinked clone roots, and removes catalog clones when the TUI session exits.

Resolve dependency outputs for units that reference a dependency in a hook, extra_arguments, or remote_state block

Resolving a unit's dependency outputs for a downstream unit no longer fails when that unit references its own dependency in:

  • a before_hook, after_hook, or error_hook
  • an extra_arguments block
  • a remote_state block

Previously these raised There is no variable named "dependency" on the downstream unit, and a remote_state reference could crash Terragrunt.

Limit IaC engine archive extraction

Terragrunt now protects developer machines and CI runners from engine archives that expand into unexpectedly large amounts of data. If an IaC engine package is unusually large or contains too many files, Terragrunt stops processing it before it can consume excessive disk space.

--filter-allow-destroy with ...[] dependent-traversal filters no longer fails

--filter-allow-destroy --filter '...[HEAD~1...HEAD]' failed with "Too many command line arguments" or hung when the deleted unit had dependents. Terragrunt now correctly plans and destroys deleted units regardless of whether dependents are included in the run.

Fix find and list missing units inside generated stacks for Git-based filters

terragrunt find and terragrunt list with a Git-based filter (for example --filter '[HEAD^1...HEAD]') now detect units inside generated stacks. Previously they did not generate stacks in the worktrees they create for the comparison, so no unit nested in a generated stack was ever surfaced, while terragrunt run --all with the same filter targeted those units correctly.

This affected every change that lands inside a generated stack, including a modified terragrunt.stack.hcl, a change to a unit's own files, and a change to a file the stack reads via read_terragrunt_config or mark_glob_as_read.

Stacks are generated only inside the comparison worktrees; find and list still do not generate stacks in your current working directory by default.

Treat Git source ref values strictly as references

Terragrunt now passes the ref from a Git module source to git strictly as a reference when downloading through content-addressable storage. Previously a source whose ref began with a git option (for example a value starting with --) could be interpreted by git as an option rather than a reference while fetching the source.

Terragrunt now terminates git option parsing before the repository and reference arguments in its fetch, clone, and ls-remote invocations, so these values can only ever be read as the repository and reference they are meant to be. Normal refs, branches, tags, and commit SHAs continue to work unchanged.

hcl validate resolves get_original_terragrunt_dir() to the discovered unit

terragrunt hcl validate and terragrunt hcl validate --inputs now resolve get_original_terragrunt_dir() to each discovered unit's own directory instead of the directory the command was launched from. Previously, when the command ran from a parent directory that discovered units in subdirectories, any read_terragrunt_config() call that built a path relative to get_original_terragrunt_dir() resolved against the wrong directory and failed with "You attempted to run terragrunt in a folder that does not contain a terragrunt.hcl file", even though plan, apply, and run validate worked on the same configuration.

Both commands now set the original config path per discovered unit before parsing, matching the behavior of run and backend bootstrap, so relative paths resolve against the unit that owns them.

Respect -lockfile=readonly during provider caching

When you pass -lockfile=readonly to init, Terragrunt no longer generates or updates .terraform.lock.hcl while warming the provider cache. Previously the cache step could write the lock file before OpenTofu/Terraform ran, so the read-only check always passed and silently defeated the flag.

Terragrunt now leaves the lock file untouched and lets OpenTofu/Terraform enforce it, failing when the lock file is missing or incomplete. The flag is honored whether it is supplied on the command line or through the TF_CLI_ARGS or TF_CLI_ARGS_init environment variables.

run --all no longer crashes on dependency discovery with graph filters

Running run --all with a filter that expands a git range through the dependency graph (for example [HEAD~1...HEAD]...) could fail during dependency discovery, reporting that a component "is missing its working directory". Whether it happened depended on the size and shape of the changed unit's dependency closure, so the same filter succeeded on smaller branches and find was unaffected.

A dependency reached from several units at once could become visible to discovery before its working directory was set, so a concurrent traversal could read it before it was complete. Dependencies now have their working directory set before they become visible, so run --all behaves the same regardless of graph size.

terraform_binary respected by run --all when both tofu and terraform are on PATH

run --all ignored a unit's terraform_binary setting and fell back to the auto-detected default (OpenTofu when both binaries are on PATH). The per-unit options used to execute each unit are cloned from the stack options, whose binary path is the auto-detected default, and the configured value was never applied to them.

Each unit now honors its own terraform_binary, matching the behavior of a single run. Setting --tf-path or TG_TF_PATH still takes precedence over the config value.

S3 bucket creation failures report the underlying error

When creating the state bucket failed during backend bootstrap, the reported error was a misleading NoSuchBucket from a follow-up access check, hiding the actual cause. The original creation error, such as AccessDenied, is now part of the reported message.

Allow empty locals blocks in terragrunt.stack.hcl

Fixed a bug where an empty locals {} block in a stack configuration could break stack generate.

Clear error when terraform.source references a dependency output

A terraform.source that references dependency.<name>.outputs.<key> is now rejected with a message explaining that the module source must be resolvable before dependencies are evaluated.

Terragrunt resolves the source while discovering units and building the run queue, before any dependency has run, so such a source can never be satisfied. Previously it surfaced a cryptic decode error.

🧪 Experiments Added

oci - Module sources from OCI registries

The oci experiment has been added as the gate for downloading source code (including OpenTofu modules) from OCI Distribution registries using oci:// schema URLs in Terragrunt configurations (including terraform.source attributes). This targets the same registries OpenTofu 1.10 supports natively, such as Amazon ECR, GitHub Container Registry, Azure Container Registry, Google Artifact Registry, and self-hosted or air-gapped registries.

Enabling the experiment has no behavioral effect yet: the getter that will resolve oci:// sources is not wired into source downloading, so oci:// sources still fail to download. Functional support will land in follow-up releases, gated by this experiment.

For setup steps, see the experiment documentation.

version-attribute - Resolve registry modules from a version constraint

The version-attribute experiment has been added to gate a new version attribute on the terraform block. It holds a version constraint (such as ~> 3.3 or >= 1.0.0, < 2.0.0) for a tfr:// registry module, and Terragrunt resolves it to the highest published version that satisfies the constraint before downloading:

terraform {
  source  = "tfr://registry.opentofu.org/terraform-aws-modules/vpc/aws"
  version = "~> 3.3"
}

This brings the terraform block to parity with the version argument on OpenTofu and Terraform module blocks. The attribute applies to tfr:// sources only, and cannot be combined with an inline ?version= on the same source.

Enable it with --experiment version-attribute. For setup steps and the criteria for stabilization, see the experiment documentation.

⚙️ Process Updates

Friendly panic reports

Terragrunt now writes a terragrunt-crash-YYYYMMDDTHHMMSSZ-<pid>.log file when it crashes.

The report includes runtime details, the command line, the panic message, and the stack trace. You can conveniently share this file (after reviewing for sensitive information) to report panics if Terragrunt crashes.

Pull Requests

✨ Features
🐛 Bug Fixes
📖 Documentation
🧹 Chores
📝 Other Changes
  • Revert "chore(deps): bump the js-dependencies group across 1 directory with 4…" by @​yhakbar in #​6433

v1.1.0

Compare Source

✨ New Features

Stack dependencies

A stack generates a tree of units from a single terragrunt.stack.hcl file. Wiring one of those units to another used to mean defin

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (in timezone Europe/Oslo)

  • Branch creation
    • Monday through Friday (* * * * 1-5)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box


ℹ️ Renovate runs on an hourly schedule, but you can manually trigger an immediate run by starting 👉 this workflow 👈

@kjoremiljo-renovate
kjoremiljo-renovate Bot requested a review from a team as a code owner January 1, 2026 12:20
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch from aaf46c4 to 8a1f7e8 Compare January 8, 2026 16:16
@kjoremiljo-renovate kjoremiljo-renovate Bot changed the title chore(deps): update dependency oslokommune/ok to v5.16.0 chore(deps): update setup-ok tool versions Jan 8, 2026
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 5 times, most recently from 5ddb2d1 to 63286e3 Compare January 16, 2026 08:18
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 6 times, most recently from 39c5709 to 49c409d Compare February 2, 2026 23:17
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 4 times, most recently from 187b7ae to 31f2dcc Compare February 9, 2026 00:44
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 4 times, most recently from 83e9d6a to 159d03b Compare February 18, 2026 16:32
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 5 times, most recently from aeac82b to a8f80a7 Compare February 27, 2026 13:37
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 3 times, most recently from 1453478 to bc78ade Compare March 3, 2026 21:20
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 7 times, most recently from 972f32a to a5cbedf Compare April 1, 2026 08:41
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 3 times, most recently from 0b93e7b to dd45c77 Compare April 6, 2026 18:32
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 3 times, most recently from b15cbce to 05ed531 Compare April 17, 2026 11:33
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 3 times, most recently from 1e9b887 to 719765e Compare April 24, 2026 07:49
@kjoremiljo-renovate kjoremiljo-renovate Bot changed the title chore(deps): update setup-ok tool versions chore: update setup-ok tool versions Apr 24, 2026
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 3 times, most recently from f345339 to 6ea494a Compare April 24, 2026 08:29
@kjoremiljo-renovate kjoremiljo-renovate Bot changed the title chore: update setup-ok tool versions Update setup-ok tool versions Apr 24, 2026
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch from 6ea494a to 0aaffac Compare April 24, 2026 08:37
@kjoremiljo-renovate kjoremiljo-renovate Bot changed the title Update setup-ok tool versions chore: update setup-ok tool versions Apr 24, 2026
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 2 times, most recently from c46a4cd to 047d378 Compare April 24, 2026 08:57
@kjoremiljo-renovate kjoremiljo-renovate Bot changed the title chore: update setup-ok tool versions deps: update setup-ok tool versions Apr 24, 2026
@kjoremiljo-renovate
kjoremiljo-renovate Bot force-pushed the ok-renovate/setup-ok-tool-versions branch 3 times, most recently from 7308221 to 699b23e Compare April 27, 2026 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants