Automated model-profile refresh PRs (e.g. #38210) ship a static template
body, so a reviewer has to open *Files changed* and read large blocks of
generated data to learn what actually moved. Because the underlying
profile data is fully structured, we can describe the changes
deterministically — no LLM, no hallucination risk.
This adds a `langchain-profiles summarize` subcommand that compares the
working-tree `_profiles.py` files against a git ref and renders a
skimmable Markdown summary: models added (with a short capability
descriptor), models removed, and per-field capability changes
(context/output tokens, modalities, tool calling, reasoning, etc.),
grouped by provider and capped so huge refreshes stay readable. Profiles
are read with `ast.literal_eval` rather than imported, so the generated
data file is never executed.
Example output for a refresh that adds a model and bumps an output
limit:
```
## Summary of changes
**1 added · 0 removed · 1 changed** across 1 provider(s).
### openai
**➕ 1 added**
- `gpt-6-preview` — 1,000,000 ctx, 128,000 out, text+image+audio in, reasoning, tools
**✏️ 1 changed**
- `gpt-3.5-turbo`: max output tokens 4,096 → 16,384
```
Made by [Open
SWE](https://openswe.vercel.app/agents/9bcbf182-effc-ba9b-0df3-afac620ad152)
---------
Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
Adds a manual release workflow input,
`skip-prior-published-package-checks`, for core releases.
The workflow dispatch dropdown supports:
- `none`
- `anthropic`
- `openai`
- `all`
When a partner is selected, that matrix entry records an explicit
skipped step and does not run the prior-published package test. The
default remains `none`, so existing release behavior is unchanged unless
the release operator opts into a skip.
AI-agent assistance was used to prepare this workflow update.
External contributors now get clearer guidance when the issue-link check
closes a PR before maintainer assignment. The auto-close copy
distinguishes the intended flow from the recovery path for PRs that were
opened early.
Release validation now covers more of the compatibility surface before
packages ship. The release dependency check also handles coordinated
monorepo version bumps explicitly, so release PRs can verify
published-package installability without failing on sibling package
versions that will be published by the same PR.
## Changes
- Run partner package unit tests, not just integration tests, when
validating previously published partner packages against the newly built
`langchain-core` wheel.
- Treat dependencies satisfied by package versions introduced in the
same release PR as expected unpublished siblings, stripping only those
pins before resolving runtime dependencies against PyPI.
- Compare changed manifests against the PR base to detect same-PR
package version bumps using static `[project]` metadata and
canonicalized package names.
- Preserve resolver-affecting `[tool.uv]` settings such as `prerelease`,
`constraint-dependencies`, and `override-dependencies` in the filtered
manifest while still dropping workspace sources.
- Add a maintainer bypass label, `release-deps: acknowledged`, for
reviewed coordinated releases that intentionally fall outside the
detected same-PR bump path.
- Surface captured resolver output and distinguish likely transient
PyPI/index failures from unsatisfiable dependency pins.
Following on the heels of #35293
TODO:
- Packages outside of this repo (e.g. LiteLLM, Nvidia, Google, AWS)
---
## Summary
Surface partner package versions in `metadata.versions` on LangSmith
traces. Mirrors the JS SDK's `_addVersion()` pattern
([langchainjs#10106](https://github.com/langchain-ai/langchainjs/pull/10106)).
Each model constructor records its package version via `_add_version()`
on `BaseLanguageModel`. The version dict accumulates through the class
hierarchy — `langchain-core` is added in
`BaseLanguageModel.model_post_init`, `langchain-openai` in
`BaseChatOpenAI._set_openai_chat_version`, and each leaf partner in its
uniquely-named `model_validator`. Traces end up with:
```json
{
"metadata": {
"versions": {
"langchain-core": "1.4.5",
"langchain-openai": "1.3.0",
"langchain-xai": "1.2.2"
}
}
}
```
### Changes
- `BaseLanguageModel._add_version(pkg, version)` — appends to
`self.metadata["versions"]`; accepts any `Mapping` type; emits a warning
if a non-mapping value is found and replaced
- `BaseLanguageModel.model_post_init` — adds `langchain-core` version;
calls `super()` for MRO safety
- `_merge_metadata_dicts` — one-level-deep (non-recursive) merge for
nested dict metadata keys
- `CallbackManager.add_metadata` — uses `_merge_metadata_dicts` instead
of flat `dict.update()` so nested metadata dicts (like `versions`)
coexist rather than clobber
- `merge_configs` — uses `_merge_metadata_dicts` for config merging
**Partners:**
- Each now calls `self._add_version("langchain-<pkg>", __version__)`
### Design decisions
- **Constructor-based, not `_get_ls_params`-based** — versions flow
through `self.metadata` (local metadata on traces), not through
`LangSmithParams`. This matches JS and makes child-class version
inheritance automatic (no merge/clobber issues).
- **`versions` is local (non-inheritable) metadata** — `self.metadata`
is passed to `CallbackManager.configure` as `local_metadata`
(`add_metadata(..., inherit=False)`), so `versions` is attached **once
per chat-model run** and is **not** propagated to child runs or
duplicated onto every streaming chunk. This is intentionally the
opposite of the inheritable-per-chunk metadata that #36588 was reducing
for performance — `versions` does not regress that path.
- **`add_metadata` deep-merge is a correctness fix, not just for
versions** — previously `add_metadata`/`merge_configs` did a flat
top-level `dict.update`/spread, so any nested metadata dict baked into a
config (e.g. via `.with_config({"metadata": {...}})`) would be wholly
replaced when a caller also passed `metadata`. `_merge_metadata_dicts`
merges one level deep so user-provided `config.metadata.versions` and
model-set `versions` coexist instead of clobbering. The merge runs once
per `configure` (not per chunk), so it is off the streaming hot path.
- **One level deep only** — `_merge_metadata_dicts` is deliberately
*not* a recursive deep merge; values nested more than one level are
last-writer-wins. This covers the `versions` case without the
ambiguity/cost of arbitrary-depth merging.
- **Warn on non-dict `metadata["versions"]`** — if a user sets
`metadata={"versions": "some-string"}`, `_add_version` emits a warning
and replaces the value with the version dict rather than silently
discarding user data or crashing. This is a soft breaking change for
anyone who previously stored non-dict values at this key.
### Follow-ups (tracked separately, out of scope here)
- JS `mergeConfigs` still flat-spreads nested metadata, so
`metadata.versions` can still clobber on the JS side until an equivalent
deep-merge lands.
---
Made by [Open SWE](https://openswe.vercel.app)
---------
Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
Release jobs can now be given an expected package version and will stop
early if that value does not match the package metadata. The workflow
also checks PyPI for an existing normalized release so duplicate version
attempts fail before build and publish steps continue.
Release PRs now get an earlier dependency-resolution check before merge,
catching unpublished intra-monorepo pins before they can produce broken
wheel metadata. The minimum-version helper also fails with a clear error
when no published PyPI version satisfies a declared constraint, instead
of emitting an invalid `pkg==None` requirement.
The release workflow's `mark-release` job downloads built wheels to
`<package>/dist/` but told `ncipollo/release-action` to glob `dist/*`.
Because JS actions don't honor `defaults.run.working-directory`, that
pattern resolved against the repo root, matched nothing, and logged
`Artifact pattern :dist/* did not match any files`. The warning is
non-fatal, so tags and releases were still created — just with no assets
attached. Verified across published releases (`langchain-groq`,
`langchain-core`, `langchain-openai`, `langchain-anthropic`): every one
has an empty asset list.
Closes#37997
Forked repositories with Actions enabled currently run the scheduled
model profile refresh without access to the GitHub App secrets used to
open the automated PR. Guarding the job to the `langchain-ai` owner
prevents noisy daily failures on forks while preserving the scheduled
refresh for the main repository.
## Changes
- Added a repository-owner guard to the `refresh-profiles` job so
`refresh_model_profiles` only runs under `langchain-ai`.
- Kept the existing reusable workflow invocation and bot secret wiring
unchanged for the canonical repository.
PR authors get clearer guidance for writing descriptions that reviewers
can understand quickly. The template and contributor guidance now ask
for a short explanation of who benefits, what problem they had, and how
the change solves it instead of a generic summary.
Release validation now covers the release paths that were intended but
not actually exercised. Manual core and `langchain_v1` releases use
short dropdown inputs, so the dependent-package test gate needs to match
those values in addition to full `libs/...` paths.
The `🚀 Publish to PyPI` job no longer starts until `🔄 Test prior
partners against new core` finishes. Previously that dependency was
commented out, so a core release could publish to PyPI in parallel
with—or before—the integration tests that install the new unreleased
core against already-published partner packages, defeating their purpose
as a pre-publish gate.
## Changes
- Add `test-prior-published-packages-against-new-core` to the `publish`
job's `needs`, so publishing blocks on those partner integration tests
completing.
- The existing `if: ${{ !cancelled() && !failure() }}` guard is
unchanged: publish proceeds only if the gate **succeeded or was
skipped**, and fails closed if the partner tests fail. For non-core
releases the partner-test job short-circuits with `exit 0`, so this adds
no friction outside `libs/core` releases.
Bumps the uv pin in `.github/actions/uv_setup/action.yml` from `0.11.15`
to [`0.11.17`](https://github.com/astral-sh/uv/releases/tag/0.11.17).
Opened automatically by `bump_uv_pin.yml`. Mirror availability on
`releases.astral.sh` was verified before this PR was created, so CI
should not race the fallback.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Ports langchain-ai/deepagents#3626. Adds a workflow that clears the
`waiting-on-author` label from an issue or PR as soon as the original
author posts a follow-up comment, closing the manual loop where
maintainers had to remember to strip the label after a reply landed.
Add job-level `concurrency` to the scheduled integration tests so
per-package shards from overlapping workflow dispatches don't hit the
same live API credentials at once — e.g. a manually triggered
`anthropic` run colliding with the daily `all libs` run.
Wire LangSmith tracing into the scheduled integration test workflow so
partner test runs emit traces to a shared project with GitHub Actions
metadata attached. Makes failures traceable back to the originating
workflow run, sha, and matrix shard without hunting through CI logs.
## Usage
- Filter the `oss-python-integration-tests` project by the
`github-actions` tag to see only CI runs; add a `sha-<sha>` or
`working_directory=<partner>` filter to narrow to a specific commit or
partner shard.
- From a failing trace, open the `github_run_url` metadata field to jump
directly to the originating workflow run; `github_run_attempt`
disambiguates reruns.
- Tags are flat strings (good for facets); structured fields like
`python_version` and `working_directory` live in metadata for richer
querying.
Fast-track companion to #37643.
GitHub's `workflow_dispatch` event is only discoverable when the
workflow file exists on the default branch — even though the workflow
code that runs comes from the `ref` passed to the dispatch. This PR
lands the `Middleware Evals` workflow file on master so that #37643
(which adds `libs/langchain_v1/tests/evals/`) can be dispatched against
the feature branch via:
```bash
gh workflow run middleware_evals.yml \
--ref nh/todo-middleware-loop-contract \
--field models='claude-sonnet-4-6,...'
```
without first merging the full eval framework.
## Caveats
- The workflow's pytest invocation depends on
`libs/langchain_v1/tests/evals/` and the partner SDK list, neither of
which exists on master yet. Dispatching with `--ref master` before
#37643 lands will fail at pytest collection. That's the intended
behavior — the workflow's purpose is to dispatch against branches that
ship the eval suite.
- Once #37643 merges to master, this workflow file already matches what
#37643 adds. The merge will be a no-op for `middleware_evals.yml`
itself.
Adds `aws`, `google-genai`, and `google-vertexai` to the manual-run
`working-directory` dropdown on the `⏰ Integration Tests` workflow.
These partners live in external repos (`langchain-ai/langchain-google`,
`langchain-ai/langchain-aws`) and were previously only reachable via the
free-form `working-directory-override` input despite the job already
checking them out into `libs/partners/`.
Bumps the uv pin in `.github/actions/uv_setup/action.yml` from `0.5.25`
to [`0.11.15`](https://github.com/astral-sh/uv/releases/tag/0.11.15).
Opened automatically by `bump_uv_pin.yml`. Mirror availability on
`releases.astral.sh` was verified before this PR was created, so CI
should not race the fallback.
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Mason Daugherty <github@mdrxy.com>
Dependabot has been stripping upper/lower bounds from internal
`langchain-*` deps in partner `pyproject.toml` files (e.g. #37288
reduced `langchain-core>=1.3.2,<2.0.0` to bare `langchain-core`). Locks
down the config so bumps preserve existing specifiers, and restores the
bounds it already mangled across the monorepo.
## Changes
- Add `versioning-strategy: increase` to every `uv` ecosystem block in
`.github/dependabot.yml` so future bumps move the lower bound in place
instead of rewriting the constraint.
- Ignore workspace-internal packages (`langchain-core`, `langchain`,
`langchain-classic`, `langchain-text-splitters`, `langchain-tests`,
`langchain-model-profiles`) on every `uv` block — these are editable
installs from local paths and their published constraints are
hand-curated for release, not Dependabot's to bump.
- Restore stripped bounds across all `libs/` packages — runtime
`dependencies` and every dep group (`test`, `dev`, `test_integration`,
`typing`, `lint`) — to `>=1.4.0,<2.0.0` for `langchain-core` and
`>=1.0.0,<2.0.0` for the other internal packages.
Four GitHub Actions workflows ported from the Deep Agents monorepo to
enforce repository hygiene rules that were not previously applied here.
## Changes
- **Fork-main PR guard**: closes PRs from forks whose head is `main` or
`master`, with a sticky comment explaining how to reopen from a feature
branch. Prevents the "Update branch" → admin-override path that lets a
`Merge branch 'master' into master` commit land on the default branch
and bypass squash-only policy. Maintainers can override with a
`bypass-fork-main-check` label.
- **Monthly uv pin bump**: opens a PR on the first of each month to
advance `UV_VERSION` in the composite setup action. Probes
`releases.astral.sh` across four architectures before committing so CI
doesn't race a lagging mirror on fresh-release days — the gap
Dependabot's `github-actions` ecosystem can't cover because it tracks
`uses:` SHA pins, not the inline `UV_VERSION` value.
- **Extras-sync validation**: a Python script (`check_extras_sync.py`)
and companion workflow that detect version-constraint drift between
`[project.dependencies]` and `[project.optional-dependencies]` across
every `libs/**/pyproject.toml`. Runs on PRs touching any
`pyproject.toml` and on pushes to `master`; is a no-op on packages that
declare no extras.
- **Banned-trailer pre-merge lint**: rejects PR descriptions containing
a `Co-authored-by: ... <noreply@anthropic.com>` trailer before the PR
reaches merge, where the org ruleset would reject the squash-push
anyway. Posts a sticky comment with remediation steps; updates it to a
"resolved" state when the trailer is removed, rather than deleting
(which requires elevated token scope on fork PRs).
Disable `uv` dependency caching throughout the release workflow so
build, validation, PyPI publish, and GitHub release jobs do not restore
shared cache state.
Release jobs already pass the built distributions through explicit
artifacts; keeping dependency caches out of this path avoids
cache-poisoning risk and makes the existing pre-release validation
comment match the actual workflow behavior.
Reorder the release pipeline so `pre-release-checks` runs before
`test-pypi-publish`. The original ordering existed because
`pre-release-checks` used to `pip install` from TestPyPI; that
dependency was removed in #28492 (Dec 2024), which switched checks to
install from the locally-built `dist/*.whl`. Since then, the TestPyPI
upload was running ahead of checks for no functional reason — and a
failed checks job left a TestPyPI version burned, with `skip-existing:
true` papering over the resulting collision on re-runs.
## Summary
The release pipeline's two \`uv pip install dist/*.whl\` calls fail when
the released package depends on a langgraph alpha that itself has
transitive prerelease deps. uv's default \`if-necessary-or-explicit\`
mode allows prereleases for first-party explicit markers (the wheel's
own deps) but rejects transitive ones, so the install fails on the wheel
— even when the wheel itself names an explicit prerelease for the
immediate dependency.
Add a workflow input \`allow-prereleases\` (default \`false\`, on both
\`workflow_call\` and \`workflow_dispatch\` triggers). When true, both
install steps pass \`--prerelease=allow\`. When false (the default),
behavior is unchanged.
The existing \`check_prerelease_dependencies.py\` step still gates
stable releases against accidentally-pinned prerelease deps.
Bumps [actions/github-script](https://github.com/actions/github-script)
from 8.0.0 to 9.0.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/actions/github-script/releases">actions/github-script's
releases</a>.</em></p>
<blockquote>
<h2>v9.0.0</h2>
<p><strong>New features:</strong></p>
<ul>
<li><strong><code>getOctokit</code> factory function</strong> —
Available directly in the script context. Create additional
authenticated Octokit clients with different tokens for multi-token
workflows, GitHub App tokens, and cross-org access. See <a
href="https://github.com/actions/github-script#creating-additional-clients-with-getoctokit">Creating
additional clients with <code>getOctokit</code></a> for details and
examples.</li>
<li><strong>Orchestration ID in user-agent</strong> — The
<code>ACTIONS_ORCHESTRATION_ID</code> environment variable is
automatically appended to the user-agent string for request
tracing.</li>
</ul>
<p><strong>Breaking changes:</strong></p>
<ul>
<li><strong><code>require('@actions/github')</code> no longer works in
scripts.</strong> The upgrade to <code>@actions/github</code> v9
(ESM-only) means <code>require('@actions/github')</code> will fail at
runtime. If you previously used patterns like <code>const { getOctokit }
= require('@actions/github')</code> to create secondary clients, use the
new injected <code>getOctokit</code> function instead — it's available
directly in the script context with no imports needed.</li>
<li><code>getOctokit</code> is now an injected function parameter.
Scripts that declare <code>const getOctokit = ...</code> or <code>let
getOctokit = ...</code> will get a <code>SyntaxError</code> because
JavaScript does not allow <code>const</code>/<code>let</code>
redeclaration of function parameters. Use the injected
<code>getOctokit</code> directly, or use <code>var getOctokit =
...</code> if you need to redeclare it.</li>
<li>If your script accesses other <code>@actions/github</code> internals
beyond the standard <code>github</code>/<code>octokit</code> client, you
may need to update those references for v9 compatibility.</li>
</ul>
<h2>What's Changed</h2>
<ul>
<li>Add ACTIONS_ORCHESTRATION_ID to user-agent string by <a
href="https://github.com/Copilot"><code>@Copilot</code></a> in <a
href="https://redirect.github.com/actions/github-script/pull/695">actions/github-script#695</a></li>
<li>ci: use deployment: false for integration test environments by <a
href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a
href="https://redirect.github.com/actions/github-script/pull/712">actions/github-script#712</a></li>
<li>feat!: add getOctokit to script context, upgrade
<code>@actions/github</code> v9, <code>@octokit/core</code> v7, and
related packages by <a
href="https://github.com/salmanmkc"><code>@salmanmkc</code></a> in <a
href="https://redirect.github.com/actions/github-script/pull/700">actions/github-script#700</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a href="https://github.com/Copilot"><code>@Copilot</code></a> made
their first contribution in <a
href="https://redirect.github.com/actions/github-script/pull/695">actions/github-script#695</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/actions/github-script/compare/v8.0.0...v9.0.0">https://github.com/actions/github-script/compare/v8.0.0...v9.0.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="3a2844b7e9"><code>3a2844b</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/github-script/issues/700">#700</a>
from actions/salmanmkc/expose-getoctokit + prepare re...</li>
<li><a
href="ca10bbdd1a"><code>ca10bbd</code></a>
fix: use <code>@octokit/core/</code>types import for v7
compatibility</li>
<li><a
href="86e48e20ac"><code>86e48e2</code></a>
merge: incorporate main branch changes</li>
<li><a
href="c1084728b5"><code>c108472</code></a>
chore: rebuild dist for v9 upgrade and getOctokit factory</li>
<li><a
href="afff112e4f"><code>afff112</code></a>
Merge pull request <a
href="https://redirect.github.com/actions/github-script/issues/712">#712</a>
from actions/salmanmkc/deployment-false + fix user-ag...</li>
<li><a
href="ff8117e5b7"><code>ff8117e</code></a>
ci: fix user-agent test to handle orchestration ID</li>
<li><a
href="81c6b78760"><code>81c6b78</code></a>
ci: use deployment: false to suppress deployment noise from integration
tests</li>
<li><a
href="3953caf885"><code>3953caf</code></a>
docs: update README examples from <a
href="https://github.com/v8"><code>@v8</code></a> to <a
href="https://github.com/v9"><code>@v9</code></a>, add getOctokit docs
and v9 brea...</li>
<li><a
href="c17d55b90d"><code>c17d55b</code></a>
ci: add getOctokit integration test job</li>
<li><a
href="a047196d9a"><code>a047196</code></a>
test: add getOctokit integration tests via callAsyncFunction</li>
<li>Additional commits viewable in <a
href="ed597411d8...3a2844b7e9">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Polish the manual release workflow (`_release.yml`) so the Actions UI is
readable at a glance — job display names, a run title that reflects the
actual published package, and a broader partner matrix for the
core-compat sanity check.
## Changes
- Add `name:` labels to each job (`📦 Build distribution`, `📝 Generate
release notes`, `🧪 Publish to TestPyPI`, `✅ Pre-release checks`, `🔄 Test
prior partners against new core`, `🚀 Publish to PyPI`, `🏷️ Tag GitHub
release`). Job IDs are unchanged, so all `needs:` references still
resolve.
- Rewrite `run-name` to resolve the dropdown value to the actual PyPI
package name — e.g. `core` → `langchain-core`, `openai` →
`langchain-openai`, with explicit remaps for the three that don't follow
`langchain-{name}` (`langchain` → `langchain-classic`, `langchain_v1` →
`langchain`, `standard-tests` → `langchain-tests`). `workflow_call`
callers passing full `libs/...` paths and manual overrides are returned
verbatim.
- Simplify `test-dependents` label to `🐍 Test dependent: ${{
matrix.package.path }} (Python ${{ matrix.python-version }})`.
we want to be able to test against the branch we run against when we are
testing external partner packages (aws, google) so overally the changes
on top of the external partners when we install the dependencies
Co-authored-by: Mason Daugherty <mason@langchain.dev>
Clean up the `workflow_dispatch` dropdowns for the release and scheduled
integration-test workflows. Showing short package names (`openai`,
`langchain_v1`, ...) instead of `libs/partners/openai` makes the UI in
the Actions tab easier to scan; the prefix now lives in the resolver
rather than every dropdown entry.
The CodSpeed workflow was failing on partner PRs because `check_diff.py`
added every partner to the `codspeed` matrix unconditionally — even when
no `tests/benchmarks/` directory exists. The workflow then ran an empty
shell block for those partners, CodSpeed saw zero benchmarks, and marked
the check as failed.
Currently no partner package has benchmarks, so this affected every
partner PR.
Both `_release.yml` and `integration_tests.yml` previously required
manually typing a package path to target a specific library. Replace the
free-text-only inputs with a dropdown of known packages plus a free-text
override for unlisted paths. The release workflow consolidates the
override-or-default resolution into a single `EFFECTIVE_WORKING_DIR` env
var to eliminate duplication across 20+ step references.
Mason Daugherty
dependabot[bot]
github-actions[bot]
Nick Hollon
ccurme
Eugene Yurtsev