* test(workers/repository): mark seven unreachable guards for v8
These are defensive paths that no input reaches, and the guards stay as
they are. What changes is that v8 now knows to skip them: the existing
`istanbul ignore` comments are inert under the v8 provider, so the
branches behind them were still being counted.
- `versioning/index`: a string input can only fail the schema with the
custom issue its own transform raises
- `versioning/conda`: pep440 always answers for a well-formed `==X.Y.*`
- `versioning/ruby`: callers only pass versions that have already parsed
- `repository/index`: only called when the repository logged a problem
- `config-migration/branch/rebase`: JSON5 output is always serializable
back to JSON
- `onboarding/pr/pr-list`: base branches are unique Record keys, so the
sort never compares one with itself
- `changelog/release-notes`: a matched release always carries its own url
- `changelog/source`: `getInRangeReleases` only returns null on paths it
already ignores
Two notes on the hints. They have to be a single-line comment directly
above the statement -- a two-line reason, or anything in between such as
an oxlint directive, breaks the association silently. And `v8 ignore
else` covers an `if` with no else, while `v8 ignore next` covers an
expression-level branch such as `??` or a ternary.
`versioning/index` also swaps `issue && issue.code` for `issue?.code`,
which is what the oxlint directive sitting in the way was suppressing.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the last five pr worker guards
None of these needed an ignore comment; each has a real input:
- `updatePrDebugData` gets a describe of its own. It is exported but was
only reached through a pr whose debug data already carried labels, so
the case where an existing pr has none went untaken.
- a `not-pending` branch whose status is no longer yellow
- a changelog error that is not a missing GitHub token
- an existing pr updated because a rebase was requested
- a platform that answers `createPr` with null, so assignees and
reviewers are skipped
With these, `update/pr/index.ts` is fully covered.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the last four branch update guards
- `bump-versions` reads the current version off disk when the pending
change for that file carries no contents. All three guards involved are
covered by one case where the file is pending in both the package file
and the artifact list with no contents on either entry. An earlier
attempt at this looked like it failed: the bump does happen, but the
result is appended to `updatedPackageFiles` rather than
`updatedArtifacts`, because the file is already pending there.
- `get-updated` keeps a package file another upgrade already wrote, for a
manager that is asked for a lockfile-only update but has no
`updateLockedDependency`.
With these, `lib/workers/repository` is fully covered.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* ci: pin the branch coverage threshold at 100
A full run on this branch reports 100% on all four metrics: statements
(49435/49435), branches (25727/25727), functions (7414/7414) and lines
(48924/48924).
Branches joins the other three at 100 rather than taking another
rounding-down step. There is no longer a margin to leave: any new
uncovered branch is a regression, and the threshold should say so.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the dependency dashboard guards
- a repository with no dashboard issue yet, so nothing is read back into
the config
- a dashboard rendered with an empty header and with abandonment
reporting turned off
- two vulnerabilities for the same package, which are grouped under one
entry rather than recorded twice
With these, `dependency-dashboard.ts` is fully covered.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover a locked update that reports no files
`updateLockedDependency` can answer `updated` without handing back any
file contents. Every test supplied files alongside that status, so the
guard that skips merging them went untaken.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover a changelog release read from cache
Every changelog test started from an empty package cache, so the branch
that reuses a cached release rather than fetching it went untaken.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* ci: ratchet the branch coverage threshold
A full run on this branch reports 100% statements (49441/49441), 100%
functions (7414/7414), 100% lines (48930/48930) and 99.92% branches
(25723/25742), up from 99.89% on the branch below. The threshold moves to
99.90, keeping the same rounding-down margin as before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover five pr body and warning guards
- an upgrade with no release notes of its own, which gets no summary
title while the branch as a whole has notes
- an upgrade with no homepage, source or dependency url, whose name is
therefore left unlinked
- an upgrade that defines no pr body columns
- an assignee list that filtering empties out
- a second warned dependency in a package file that is already listed,
so the file is not recorded twice
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover four changelog guards
- `massageName` gets a describe of its own: it is exported but was only
ever reached through a release that carried a tag, so the no-version
path and the empty-result path went untaken
- a lone in-range release with no earlier one to prepend
- a bitbucket tree holding exactly one changelog candidate, so nothing is
logged about choosing between several
- a bitbucket-server source url that parses but matches neither the git
nor the web repository pattern
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover both extract failure paths
- a manager whose `extractAllPackageFiles` returns null, so there is
nothing to massage dep names in
- a file whose `extractPackageFile` returns nothing, so it contributes no
package file
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* ci: ratchet the branch coverage threshold
A full run on this branch reports 100% statements (49491/49491), 100%
functions (7384/7384), 100% lines (48981/48981) and 99.86% branches
(25726/25761), up from 99.82% on the branch below. The threshold moves to
99.84, keeping the same rounding-down margin as before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover four process guards
- a libyear update released before the version currently in use, which
yields a negative age and is therefore not counted
- a pr that is closed, and one raised from the onboarding branch, neither
of which counts towards the concurrent pr limit
- a second base branch whose package files do not displace the first
one's, on a platform that cannot sync a fork with its upstream
The fork case redefines `syncForkWithUpstream` rather than deleting it,
the same way the migration branch spec handles `refreshPr`.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the extract cache guards
- a cached extract whose manager fingerprints all still match, so the
cache is reusable; the test reads the expected fingerprint out of
`hashMap` rather than hard-coding a hash that regenerates
- an extract that is told not to overwrite the cache
- a cached scan for a branch that is still a configured base branch, so
it survives the clean-up that drops the others
With these, `lib/workers/repository/process` is fully covered.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the branchPrefixOld miss
`prAlreadyExisted` retries the lookup under the old branch prefix, but
every test either hit on the first lookup or on the second, so the case
where both miss went untaken.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* ci: ratchet the branch coverage threshold to 99.87
The tests added after the earlier bump in this branch close eight more
branches. A full run now reports 100% statements (49491/49491), 100%
functions (7384/7384), 100% lines (48981/48981) and 99.89% branches
(25734/25761). The threshold moves from 99.84 to 99.87, keeping the same
rounding-down margin as before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover three changelog embedding guards
The pr worker copies release notes off each upgrade's changelog result.
Three of its guards were never taken because every test supplied a
complete result for a distinct repository:
- a changelog with no project, so no repo name is recorded
- a changelog with a project but no versions, so no releases are copied
- a second upgrade for a repository whose notes were already committed,
which is skipped rather than repeated
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the pr note and closed-pr guards
`handle-existing.ts` had no spec of its own and was only reached through
the branch worker, so none of its early exits were exercised. Give it
one, covering an open pr, a suppressed notification, a branch that is
already gone, each of the three ignore messages, and both dry-run paths
in each function.
Also cover a pr body with no notes at all, extra notes where none of the
three conditions hold, and a config warning issue raised from an error
that carries no validation details and whose issue is neither created
nor updated.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover five config migration guards
- a `package.json` that carries no `renovate` key, so nothing is deleted
from it before it is rewritten
- a platform with no `refreshPr`, which the migration branch check has to
tolerate
- an old migration branch that is already gone, so there is nothing to
delete before the new one is created
- an editorconfig that sets no maximum line length
- a migration pr with no footer configured
The platform case redefines `refreshPr` rather than deleting it: the
mocked module object refuses deletion but allows redefinition.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the onboarding and reconfigure caches
- deleting and updating the onboarding cache when there is no cache
- an onboarding pr whose closing comment is suppressed
- a reconfigure cache written together with an extract result
Also drop the `if (extractResult)` in the reconfigure check: the catch
above it returns, so the variable is always set by the time the comment
is ensured, and the compiler narrows it on its own.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/repository): cover the update flattening guards
- a config whose `semanticCommits` is already decided, so no detection
runs while flattening
- a semantic commit with no scope configured
Also drop the first `packagePath.length > 0` check while flattening:
`String.split` always yields at least one element, so there is always a
file name to drop. The check after the splice stays, since that one can
leave the array empty.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* ci: ratchet the branch coverage threshold
A full run on this branch reports 100% statements (49468/49468), 100%
functions (7381/7381), 100% lines (48958/48958) and 99.82% branches
(25709/25755), up from 99.73% on the branch below. The threshold moves to
99.80, keeping the same rounding-down margin as before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* Apply suggestion from `@secustor`
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
---------
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* test(versioning): cover four uncovered guards
- `cargo`: a converted range whose operators are already attached to
their versions, so `npm2cargo` leaves the elements alone
- `hashicorp`: a widen on a complex range ending in `>=`, which the
underlying semver implementation refuses and returns null for
- `poetry`: a version list holding an unparseable entry, for both
`getSatisfyingVersion` and `minSatisfyingVersion`, plus the same widen
refusal, which falls back to the current value
- `swift`: an open-ended range whose bound is not a valid semver
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(versioning): drop two guards that cannot be false
- `hermit`: `major` is the only mandatory group in the version regex, so
the `if (major)` around the first release segment always holds; the
sibling parser already pushes it unconditionally
- `rpm`: after `c1 === c2` is ruled out, one of `c1 > c2` and `c1 < c2`
must hold, so the second comparison becomes a ternary
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(versioning/gradle): cover three uncovered guards
- `getMajor` on a version whose leading token is not a number
- `getSatisfyingVersion` with a later match that is not greater than the
one already held
- `minSatisfyingVersion` with a later match that is not smaller than the
one already held
Two branches in `compare.ts` are still open and are looked at next.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(versioning/ivy): cover a later match that is not the greatest
`getSatisfyingVersion` kept every matching version it walked past, so the
guard that holds on to the one already found was never taken.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(versioning): drop three guards that cannot be false
- `gradle`: `tokenCmp` compares two tokens whose only types are `Number`
and `String`, so once both-numbers and both-strings are handled
exactly one side is a number; the chain becomes a ternary and the
unreachable `return 0` goes
- `ivy`: `tokenize` always yields at least one token for a non-empty
version, so the length check around the last one always holds
- `ivy`: `rangeToStr` only returns null for a null range, which the
`length === 1` check above it already rules out
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(versioning/nuget): cover a later match that is not the greatest
Both loops in `getSatisfyingVersion` walked version lists that only ever
climbed, so the guard that holds on to the candidate already found was
never taken -- once for a bracket range, once for a bare version acting
as a minimum.
Also pin down that a floating range needs a major component: `-*` alone
does not parse.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(versioning): drop three more guards that cannot be false
- `maven`: the interval picked for auto-extension is only picked when the
new value is at or past its upper bound, and that upper bound is the
lower one incremented, so the new value never sorts below the lower
bound
- `maven`: an interval never has both bounds open, because the parser
only nulls one side when the other is a version
- `nuget`: a floating range always carries a major component, so neither
the parser's NaN check nor the serializer's undefined check can fail
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(versioning/pep440): drop three unreachable range paths
`updateRangeValue` handles `!=`, a `.*` prefix, `~=`, `==` and `<=`
itself, `handleUpperBound` handles `<`, and `parseCurrentRange` rejects
`===`. Only `>` and `>=` can reach `handleLowerBound`, so its operator
check always holds and it never returns null. Making it total removes
the null check at the call site as well.
This does drop the `logger.error` that followed, which was guarded by a
comment saying it could not happen unless pep440 itself changed.
`isLessThanRange` classifies the same fixed operator set, so the last
check there is the only one left and its fallback was dead.
`divideCompatibleReleaseRange` only ever sees a `~=` version, and pep440
requires at least two release components after that operator, so there
is always a component to drop. A new test pins down that `~=7` is not a
valid range.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(versioning): cover three more uncovered guards
- `elm`: a widen where the new version sits below the lower bound, so
the upper bound is kept rather than extended
- `hex`: a widen on a complex range ending in `>=`, which the underlying
semver implementation refuses and returns null for
- `rust-release-channel`: a concrete current version paired with a
channel name as the new version, which falls through to the new
version unchanged
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(versioning): drop two more guards that cannot be false
- `composer`: `getNewValue` falls back to the new version whenever
nothing else matched, so it never returns null and the recursive call
in the or-range path always has a value to work with
- `docker`: a version's prerelease is always a string, so once an empty
one on either side is handled, the remaining pair is both non-empty
and unequal
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(config,datasource): cover two more uncovered guards
- `config/validation`: `hostRules[].allowInternal` nested inside a
`packageRules[]` entry, which reports a plain configuration error
rather than a security one, because nested host rules are never applied
- `datasource/docker`: a non-list manifest whose response carries no
`docker-content-digest` header, so the digest falls back to the hash of
the manifest body
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(config,datasource): unwind three branches v8 could not count
- `config/decrypt` and `datasource/docker/common` each picked a response
with an `await` inside a ternary. v8 gives the branch that follows such
a ternary a negative hit count, which the reporters read as uncovered
even though both paths run. Spelling the choice as an if/else makes the
count come out right; behaviour is unchanged.
- `datasource/index` and `datasource/npm/npmrc` each ended an exhaustive
chain with an `else if` whose implicit else v8 counts but nothing can
reach: `registryStrategy` is one of three literals, and `npmrc` starts
as an object and is only ever reassigned to one.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/global): cover seven uncovered guards
The config parsers rewrite legacy boolean spellings of `dryRun`,
`requireConfig` and `platformCommit`, but nothing passed a value that was
already current, so the fall-through of each chain went untaken. Cover it
from both the CLI and the environment.
Also cover a datasource env var that names no auth field, one whose value
is undefined, a default config file that cannot be read, and the error
`isLimitReached` throws when asked for a concurrent limit without a
branch config. That last one had an ignore hint saying it should not
happen; the error message documents the contract, so it is now tested and
the hint is gone.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(workers/global): drop a guard that cannot be false
`getConfig` in the additional-config-file parser returns early unless
`RENOVATE_ADDITIONAL_CONFIG_FILE` is set, so by the time a parse error is
being classified the variable is always present.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(workers/repository): drop a dead changelog file lookup
The gitea, gitlab and forgejo changelog sources each declared `files` as
an empty array and then guarded the only assignment to it with
`if (!files.length)`, which is always true one line after the
declaration. Collapse it to the filter itself.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* ci: ratchet the branch coverage threshold
A full run on this branch reports 100% statements (49471/49471), 100%
functions (7381/7381), 100% lines (48961/48961) and 99.73% branches
(25690/25759), up from 99.53% before this branch's work. The threshold
moves to 99.71, keeping the same rounding-down margin as before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(config,datasource): say why the ternary was unwound
Both sites now carry a comment explaining that the if/else is deliberate:
v8 gives the branch following an `await` inside a ternary a negative hit
count, which the coverage reporters read as uncovered.
`apiCheckResponse` also gets an explicit `HttpResponse<unknown>` type,
which is what the two branches have in common and what
`isECRMaxResultsResponse` already expects.
Also fix a type error in the new config file spec: the `pathExists` spy
needs the same `as never` cast the surrounding tests use.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* refactor(versioning/pep440): use a template literal in handleLowerBound
The exclude-style return is the one line this branch rewrote in that
function, so it now builds its string with a template literal instead of
the `+` operator.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test(workers/global): drop the cast from the limits throw test
Calling the overload with a non-null assertion on the config argument
says the same thing without retyping the whole function.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
ci: ratchet the branch coverage threshold
A full run on this branch reports 100% statements (49406/49406), 100%
functions (7365/7365), 100% lines (48896/48896) and 99.53% branches
(25636/25755), up from 99.16% before the manager coverage work. The
threshold moves to 99.51, keeping the same rounding-down margin as
before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
build: ratchet the branch coverage threshold
A full run on this branch reports 100% statements (49249/49249), 100%
functions (7333/7333) and 99.16% branches (25479/25696), up from 98.72%
(25434/25765) before the manager coverage work. The threshold moves to
99.14, keeping the same rounding-down margin as before.
Statements, functions and lines are already pinned at 100 and stay
there.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* test: close remaining line coverage gaps
A full coverage run reported three uncovered lines:
- `rez` versioning: `rez2pep440()` was never called with a plain version,
because `getNewValue()` short-circuits via `matchVersionPrecision()`
whenever the new version is valid for npm. A four-component rez version
is not, so it reaches the pep440 path.
- `nuget` v3: only the inner nuspec 404 was covered, never a 404 escaping
from the `.nupkg` download into the outer catch.
- `github` platform: the statement after `await` in the GitHub App branch
is a v8/source-map false negative - it runs, but is counted zero. The
branch used to carry the `v8 ignore` comment, which moved away with the
`ghHostname` block in #44587.
Co-Authored-By: Claude Opus 5 <michael.kriese+claude-code@mend.io>
* build: ratchet coverage thresholds
A full run now reports 100% statements (49776/49776), 100% lines
(49256/49256), 100% functions and 98.72% branches (25756/26089), so the
thresholds move up accordingly. Branches keep the same rounding-down
margin as before.
Co-Authored-By: Claude Opus 5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
Sets each floor to the current measured coverage, rounded down to two
decimals:
statements 99.993944% -> 99.99
branches 98.703754% -> 98.70
functions 100% -> 100
lines 99.993880% -> 99.99
This leaves very little slack by design: one uncovered branch is
0.00386%, so the branches floor tolerates none.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
lib/config/decrypt/legacy.ts was removed in #39111, so
getCoverageIgnorePatterns() only ever excluded a path that no longer
exists, and the TEST_LEGACY_DECRYPTION workflow env var that gated it
was read by nothing else.
Coverage is unaffected: a full run reports the same numbers before and
after, so the thresholds stay as they are.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
ci: tighten statements and functions thresholds
Both metrics have headroom against the current measured coverage
(statements 99.9899%, functions 99.9864%), so the floors can move up
without depending on any other pull request landing first.
Co-authored-by: Claude Opus 5 <michael.kriese+claude-code@mend.io>
Due to a long-standing issue with `semantic-release` not checking if
`#...` reference is for a Discussion or Issue, if a contributor says
`Closes #<discussion>`, then our release process fails.
We can extend our existing checks to try and catch this in the PR
itself, as users may not read the big warning that says "don't add a
Discussion here".
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As per request in #45462, we can perform a prefactor to ensure that our
scripts for CI-related functionality are part of `tools`, so they're
linted appropriately.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
When running the Release job, we restore our `node_modules` cache via
`setup-node`. This leads to `semantic-release` executing - with
`contents: write`, `packages: write`, `id-token: write` and Docker Hub
credentials - the release process.
If we were to have a poisoned cache, this could lead to backdoored npm
packages and Docker images.
Although not currently exploitable, we should further harden this by:
- never using the cache for `release` jobs
- requiring a full `pnpm install --frozen-lockfile` on release jobs
- increasing the build time slightly on release jobs
This ensures that we don't leave ourselves vulnerable to cache poisoning
in the future.
It appears that zizmor's `cache-poisoning` audit covers this pattern,
but doesn't recognise a branch-push `semantic-release` job as a release
workflow, so won't flag regressions here.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
As per the previous commit, we currently don't lint our composite
actions, but should do.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
The Unified Agent scan passes `secrets.WS_ORG_TOKEN` as a `-apiKey`
CLI argument. Actions masks it in logs, but command-line arguments
are visible in the runner's process table to anything else running on
the machine.
As the Unified Agent reads any configuration parameter from a
`WS_`-prefixed environment variable, we can supply `WS_APIKEY` via
`env:` and drop the argument.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
To avoid potentially expanding a `discussion.created_at` event, we can
make sure we don't interpolate it, by injecting it in via `env`.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
To reduce risk of template injection, we can pass secrets and inputs as
an `env` input, which avoids shell expansion and hardens our usage.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
To make sure that we cover these steps explicitly, we can add a check
for them in `test-success`.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
As we're missing the `${{ }}`, we're passing in the literal string
`github.event_name ...` to `fail_ci_if_error` which may not evaluate as
expected.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
So we can run them both in parallel, speeding up the overall run time.
This may lead to a case where we run `build-docs` in the case a linting
failure is hit, but it also allows running them both in parallel which
could save ~1m of wasted waiting time.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
renovate[bot]