This change stops agentic workflows from opening GitHub issues when a
run fails due to workflow/tooling conditions such as missing-tool
reports or token-budget exhaustion. It applies the repository-wide
suppression suggested by the failure issue itself, so these runs can
still fail without creating issue noise.
- **What changed**
- Added `safe-outputs.report-failure-as-issue: false` to each top-level
agentic workflow source under `.github/workflows/*.md`
- Regenerated the corresponding compiled `.lock.yml` workflows so the
runtime configuration matches the source frontmatter
- **Effect**
- Agentic workflow runs continue to report failure in Actions
- Automatic `[aw] ... failed` issue creation is disabled for these
workflows
- Existing safe outputs such as `noop` and `missing-tool` remain
unchanged
- **Scope**
- Applied consistently across the repository’s top-level agentic
workflows, including `zipt-code-reviewer`, `build-warning-fixer`,
`code-conventions-analyzer`, `workflow-suggestion-agent`, and related
workflows
- **Configuration pattern**
```yaml
safe-outputs:
report-failure-as-issue: false
create-issue:
...
missing-tool:
create-issue: true
noop:
report-as-issue: false
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This updates `fstar-master-build.yml` so generated `.smt2` files are
preserved and discoverable from the build discussion. The discussion now
links the artifact and includes an inline preview of each generated SMT2
file (first 1000 lines).
- **SMT2 collection and packaging**
- Added an always-run step to recursively find generated `*.smt2` files
under the FStar checkout.
- Copies discovered files into a dedicated artifact staging directory
while preserving relative paths.
- **Artifact publication**
- Added artifact upload for collected SMT2 files
(`fstar-generated-smt2-${{ github.run_id }}`).
- Exposes uploaded artifact metadata to downstream steps for linking.
- **Discussion enrichment**
- Extended discussion body generation to include:
- direct artifact link (when SMT2 files exist),
- inline preview blocks with the first 1000 lines per file,
- fallback messaging when no SMT2 files are produced.
- Added size-aware truncation to keep discussion content within GitHub
body limits.
```yaml
- name: Upload generated SMT2 artifact
id: upload_smt2
if: always() && steps.collect_smt2.outputs.has_files == 'true'
uses: actions/upload-artifact@v4
with:
name: fstar-generated-smt2-${{ github.run_id }}
path: /tmp/gh-aw/agent/smt2-artifact
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
The memory-safety scan workflow already runs ASan/UBSan, but its
reporting workflow was configured to post discussions rather than filing
actionable issues. This change aligns the reporter with the expected
outcome: sanitizer findings become trackable GitHub issues.
- **Reporting output switched to issues**
- Replaced `safe-outputs.create-discussion` with
`safe-outputs.create-issue` in `memory-safety-report.md`
- Added issue labels and issue cap for controlled issue creation
- Updated workflow description text to reflect issue-based reporting
- **Prompt behavior updated for clean/noisy runs**
- Updated agent instructions to generate issue reports for actionable
findings
- Changed zero-finding behavior to `noop` (no issue spam on clean runs)
- Updated wording for failure/edge-case paths to reference issue output
- **Compiled workflow updated**
- Regenerated `memory-safety-report.lock.yml` from the markdown source
so runtime behavior matches the new safe-output contract
```yaml
safe-outputs:
create-issue:
title-prefix: "[Memory Safety] "
labels: [bug, memory-safety, automated-analysis]
max: 1
noop:
report-as-issue: false
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This change simplifies recently touched skill scripts by removing
duplicated repo-root discovery code, promoting shared root lookup to a
public API, and tightening small readability issues without changing
behavior. It keeps script semantics intact while making cross-skill
reuse explicit.
- **Shared API cleanup (`.github/skills/shared/z3db.py`)**
- Promote `_find_repo_root` to public `find_repo_root`.
- Add `require_repo_root()` for scripts that should fail-fast when root
discovery fails.
- Update library usage docstring to expose both helpers.
- Replace adjacent SQL string literals in `log()` with a single literal.
- **Deduplicate memory-safety root lookup
(`.github/skills/memory-safety/scripts/memory_safety.py`)**
- Remove local `find_repo_root()` implementation.
- Import and use shared `require_repo_root()` from `z3db`.
- **Simplify static-analysis label selection
(`.github/skills/static-analysis/scripts/static_analysis.py`)**
- Replace two-step label assignment with a single expression:
- `label = f["type"] or f["category"]`
```python
# before
label = f["category"]
if f["type"]:
label = f["type"]
# after
label = f["type"] or f["category"]
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
`build-and-report` was failing hard when the `Build FStar` step hit
prover regressions, preventing downstream reporting from running. This
change makes FStar failures non-blocking and ensures the reporting path
still executes with an explicit FStar outcome.
- **Workflow failure propagation**
- Marked `Build FStar` as non-blocking:
- added `id: build_fstar`
- added `continue-on-error: true`
- **Guaranteed reporting execution**
- Made the summary step unconditional with `if: always()` so it runs
even when FStar fails.
- **Robust summary generation**
- Passed step outcome into the script (`FSTAR_BUILD_OUTCOME`).
- Hardened file reads for missing FStar artifacts/version files.
- Report body now reflects actual FStar outcome (`success` vs
non-success) while preserving pipeline continuity.
```yaml
- name: Build FStar
id: build_fstar
continue-on-error: true
run: |
# existing FStar build commands
- name: Create discussion summary
if: always()
env:
FSTAR_BUILD_OUTCOME: ${{ steps.build_fstar.outcome }}
uses: actions/github-script@v9
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
The `build-and-report` workflow failed in `build-and-report` because
FStar was invoked with a default `OTHERFLAGS` value containing
`--smt.ho_matching true`, which current FStar no longer recognizes. This
change removes that default while keeping the input configurable for
manual runs.
- **Root cause**
- Workflow default `fstar_otherflags` was set to `--smt.ho_matching
true`.
- During `make`, FStar exited with `error: unrecognized option
'--smt.ho_matching'` (job `79905082893`).
- **Workflow changes**
- Updated `.github/workflows/fstar-master-build.yml`:
- `workflow_dispatch.inputs.fstar_otherflags.default` changed from
`--smt.ho_matching true` to `""`.
- Job env fallback `FSTAR_OTHERFLAGS` changed from `--smt.ho_matching
true` to `""`.
- Removed the outdated option example from the `fstar_otherflags` input
description.
- **Resulting behavior**
- Default scheduled/manual workflow runs no longer pass unsupported
FStar flags.
- Custom flags can still be provided via `fstar_otherflags` when needed.
```yaml
fstar_otherflags:
description: "Extra FStar OTHERFLAGS"
required: false
default: ""
# ...
FSTAR_OTHERFLAGS: ${{ github.event.inputs.fstar_otherflags || '' }}
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
The `Build FStar master with Z3 master` workflow was failing because
FStar's `karamel` submodule was not present after a shallow clone,
causing `make` to abort immediately.
## Change
- Added `--recurse-submodules` to the `git clone` call for FStar in
`.github/workflows/fstar-master-build.yml`
```diff
-git clone --depth=1 --branch "$FSTAR_REF" https://github.com/FStarLang/FStar.git /tmp/gh-aw/agent/FStar
+git clone --depth=1 --recurse-submodules --branch "$FSTAR_REF" https://github.com/FStarLang/FStar.git /tmp/gh-aw/agent/FStar
```
Failing run:
https://github.com/Z3Prover/z3/actions/runs/27072072789/job/79903014692
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This change replaces the existing agentic workflow with a standard
GitHub Actions workflow that builds Z3 and then builds FStar against
that Z3. The workflow remains parameterized for both toolchains and
supports exercising `smt.ho_matching` via configurable Z3 runtime args
and FStar `OTHERFLAGS`.
- **Workflow migration (agentic → standard)**
- Replaced `.github/workflows/fstar-master-build.md` + `.lock.yml` with
a single native workflow: `.github/workflows/fstar-master-build.yml`.
- Removed dependency on agentic frontmatter, safe-outputs, and
runtime-import flow.
- **Configurable build inputs**
- Added `workflow_dispatch` inputs for:
- `z3_ref`, `z3_cmake_args`, `z3_runtime_args`
- `fstar_ref`, `fstar_opam_switch`, `fstar_otherflags`
- `discussion_category`
- Defaults preserve the requested ho-matching exercise path:
- `z3_runtime_args: smt.ho_matching=true`
- `fstar_otherflags: --smt.ho_matching true`
- **Build and integration flow**
- Builds Z3 from configured ref in `build/release` with CMake+Ninja.
- Clones/builds FStar from configured ref, wiring it to the just-built
Z3 (including version override and PATH aliases expected by FStar).
- **Discussion reporting without agents**
- Adds an `actions/github-script` step that:
- resolves discussion category ID by name,
- posts a summary discussion with inputs, produced versions, commit, and
workflow run URL.
- **Failure diagnostics hardening**
- Added explicit failure messages for missing parsed Z3 version and
missing FStar executable.
- Added defensive handling when parsing generated version text.
```yaml
on:
workflow_dispatch:
inputs:
z3_runtime_args:
default: "smt.ho_matching=true"
fstar_otherflags:
default: "--smt.ho_matching true"
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This change adds an agentic workflow that builds the latest `master` of
Z3, then builds the latest `master` of FStar using that exact Z3 binary.
It addresses the gap where cross-project compatibility on head revisions
was not automated.
- **Workflow added: Z3→FStar head build**
- Created `.github/workflows/fstar-master-build.md` with daily + manual
triggers.
- Keeps permissions minimal (`read-all`) and uses `network: defaults`.
- **Z3 build phase**
- Checks out Z3 `master`.
- Builds `build/release/z3` via CMake + Ninja.
- Captures and parses the built Z3 version for downstream use.
- **FStar build phase wired to built Z3**
- Clones `FStarLang/FStar` `master`.
- Sets up OPAM and FStar dependencies.
- Forces FStar build to use the newly built Z3 via PATH aliases and
`OTHERFLAGS="--z3version <built-version>"`.
- **Compiled workflow artifact**
- Added `.github/workflows/fstar-master-build.lock.yml` generated from
the new source workflow.
```yaml
# Key integration point used in the workflow
PATH="/tmp/gh-aw/agent/z3-bin:$PATH" \
OTHERFLAGS="--z3version $Z3_VERSION" \
make -j"$(nproc)"
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Nikolaj Bjorner <nbjorner@microsoft.com>
This introduces an agentic workflow that continuously validates Z3→F*
integration by building Z3 from this repository’s `master` and then
building `FStarLang/FStar` from its latest `master` using that exact Z3
binary.
- **Workflow added**
- New source workflow: `.github/workflows/fstar-master-build.md`
- New compiled workflow: `.github/workflows/fstar-master-build.lock.yml`
- Triggered on `daily` schedule and `workflow_dispatch`.
- **Build orchestration**
- Checks out Z3 `master` and builds/installs it with CMake + Ninja into
`/tmp/gh-aw/agent/z3-install`.
- Clones latest `FStarLang/FStar` `master` and records the exact commit
SHA used.
- Forces F* build to use the locally built Z3 via:
- `PATH=/tmp/gh-aw/agent/z3-install/bin:$PATH`
- `Z3_EXE=/tmp/gh-aw/agent/z3-install/bin/z3`
- **Reporting + failure handling**
- On success: posts a discussion with Z3 commit/version, F* commit, and
command summary.
- On failure: opens an issue with failing phase, error summary, and log
excerpts.
- Uses safe-outputs with bounded lifetime (`expires: 14d`) and explicit
failure labeling.
```yaml
safe-outputs:
create-discussion:
title-prefix: "[F* Build] "
close-older-discussions: true
expires: 14d
create-issue:
title-prefix: "[F* Build Failure] "
labels: ["build", "fstar"]
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
## Why
Removes the three issue-oracle steps from the Ubuntu nightly job. They
have been failing every nightly run since they landed in #9688 — see
[run
26927938635](https://github.com/Z3Prover/z3/actions/runs/26927938635/job/79441695358):
- **`Clone bench (for issue-oracle smoke test)`** → exit 128 with
`fatal: could not read Username for 'https://github.com'`, because
`Z3Prover/bench` is a private repo and the workflow had no credentials
for it.
- **`Run issue-oracle smoke test`** → exit 2 because
`bench/scripts/issues_check_oracle.py` was never downloaded.
- **`Upload issue-oracle report`** → warning because the JSON report was
never produced.
All three were absorbed by `continue-on-error: true`, so the job stayed
green, but every nightly emitted two stale red error annotations and
**the smoke test never actually ran**.
## What replaces it
The smoke test has been moved to a new workflow in `Z3Prover/bench`:
[`.github/workflows/issue-oracle.yml`](https://github.com/Z3Prover/bench/blob/ci/issue-oracle-pull-z3-nightly/.github/workflows/issue-oracle.yml)
— see **Z3Prover/bench PR #2504**.
The bench-side workflow:
- runs at 04:30 UTC daily (this repo's nightly runs at 02:00 UTC + DAG,
so ~2.5 h slack);
- pulls the `z3-*-x64-glibc-*.zip` asset from **this repo's public
`Nightly` release** via `gh release download` — unauthenticated for
`Z3Prover/z3` because z3 is public, so **no cross-repo PAT and no
`BENCH_REPO_TOKEN` secret** are required;
- checks the release's `publishedAt` is < 18 h old, so a skipped/failed
upstream nightly reds the workflow instead of silently re-testing
yesterday's binary;
- runs `issues_check_oracle.py` with the exact same smoke-test budget
the deleted step used (`--max 200 --timeout 5 --wallclock 20 --jobs 0`,
outer `timeout 90`);
- uploads `issue-oracle-report.json` as an artifact (7-day retention).
## Scope of this PR
Only the three dead steps are deleted; the downstream `Upload artifact`
(`UbuntuBuild`) step and everything that depends on it
(`deploy-nightly`, etc.) are unchanged. A short comment replaces the
deleted block to direct future readers to the new home.
## Merge order
This PR can land **before, after, or simultaneously with** the
bench-side PR. There is no functional regression either way:
- Today, the deleted steps produce zero useful output (just noisy
annotations). Removing them is strictly an improvement to nightly log
signal.
- The bench-side workflow stands on its own and produces output the
moment it lands (since it pulls from the already-existing `Nightly`
release).
## Validation
- `python -c "import yaml;
yaml.safe_load(open('.github/workflows/nightly.yml'))"` → OK.
- Search confirms no remaining live references to `bench/`,
`BENCH_REPO_TOKEN`, or `issue-oracle-report.json` in `nightly.yml` (only
the explanatory comment in the deletion block).
- Diff: -56 / +9, single file.
---
**Companion PR (do not merge before this one is reviewed):**
https://github.com/Z3Prover/bench/pull/2504
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds a tightly-bounded issue-oracle smoke test as a sibling of the
existing `test_benchmarks.py` step in the nightly's `ubuntu-build` job.
The step always runs as part of every nightly, can never fail the build,
and completes in ~2 min.
## Why
`Z3Prover/bench` ships a per-issue regression corpus
(`inputs/issues/iss-N/`) plus a runner
(`scripts/issues_check_oracle.py`) that diffs current z3 output against
captured `<stem>.expected.out` byte streams. Wiring that into the
nightly gives us a daily smoke signal that detects regressions on
benchmarks distilled from real z3 issues — without requiring any z3
contributor to ever touch the bench repo.
## What
A two-step block added right after the existing `Clone z3test` + `Test`
steps in `ubuntu-build`:
1. **Clone bench (sparse, ~800 MB of ~12 GB total)**
`git clone --depth 1 --filter=blob:none --sparse
https://github.com/Z3Prover/bench bench` then `sparse-checkout set
scripts inputs/issues`.
2. **Run issue-oracle smoke test (~2 min)**
```yaml
continue-on-error: true
run: |
timeout 90 python bench/scripts/issues_check_oracle.py \
--z3 build-dist/z3 \
--all bench/inputs/issues \
--max 200 --timeout 5 --wallclock 60 \
--jobs 0 --quiet \
--json-report issue-oracle-report.json
```
The JSON report is then uploaded as a workflow artifact
(`issue-oracle-report`, 7-day retention) for inspection.
### Wall-clock bounds (defense in depth)
| Bound | Where | Purpose |
|---|---|---|
| `--max 200` | issues_check_oracle CLI | walk only first 200 of ~2,700
`iss-*` dirs (alphabetic; stable across nightlies) |
| `--timeout 5` | issues_check_oracle CLI | per-file z3 cap |
| `--wallclock 60` | issues_check_oracle CLI | hard global cap inside
the script |
| `timeout 90` | shell wrapper | belt-and-braces backstop, leaves 30 s
headroom for the script to flush its JSON report before SIGTERM |
| `continue-on-error: true` | step gate | absorbs every failure mode
(missing z3, sparse-clone failure, outer timeout firing, etc.) so the
smoke test can **never** red the nightly build |
### Scope
Only `ubuntu-build` and only one place in `nightly.yml`. The push/PR
lanes (`ci.yml`, `Windows.yml`) and the other scheduled/dispatch lanes
(`coverage.yml`, `memory-safety.yml`, `nightly-validation.yml`,
`release.yml`, `wip.yml`, `daily-test-improver`) are intentionally left
untouched so this gate runs exactly once per night.
## Local verification
On Mac (16 cores, capped to 8 jobs by `--jobs 0` resolving to `min(jobs,
cores)`):
```
[issues_check_oracle] 368 file-check(s) | timeout=5s | wallclock=60s
=== summary ===
total: 368 ok: 286 DIFF: 4 (per-file timeouts) skipped: 78
elapsed: 8.3s / 60s
exit code: 0
```
GHA Ubuntu (4 cores → 4 jobs) extrapolation: ~17 s typical, well under
all wall-clock caps.
### Adversarial cases (all leave the workflow green via step-level
`continue-on-error: true`)
| Failure mode | Result |
|---|---|
| z3 binary missing | each per-file run records `exec-error`, script
summary-exits 0 → green |
| Sparse clone fails (previous step's continue-on-error absorbs it) |
oracle finds no `bench/` → script `sys.exit(1)` → step's
continue-on-error absorbs → green |
| Wallclock fires | script writes report with `wallclock_hit: true`,
exits 0 → green |
| Outer `timeout 90` fires | SIGTERM → bash exits 124 → step's
continue-on-error absorbs → green |
## Companion bench-repo PR
The data side of this (per-bench sidecar schema, `bug-K.json` +
`<stem>.expected.out`, oracle rewrite) lands in `Z3Prover/bench` as PR
[#2503](https://github.com/Z3Prover/bench/pull/2503). The nightly step
here depends on that PR's `scripts/issues_check_oracle.py` and the
migrated corpus. Both PRs should be merged together; bench can also
merge first (the script handles a missing corpus gracefully).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Bumps [github/gh-aw-actions](https://github.com/github/gh-aw-actions)
from 0.76.1 to 0.77.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/github/gh-aw-actions/releases">github/gh-aw-actions's
releases</a>.</em></p>
<blockquote>
<h2>v0.77.0</h2>
<p>Sync of actions from <a
href="https://github.com/github/gh-aw">gh-aw</a> at
<code>v0.77.0</code>.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="b11be78086"><code>b11be78</code></a>
chore: sync actions from gh-aw@v0.77.0 (<a
href="https://redirect.github.com/github/gh-aw-actions/issues/122">#122</a>)</li>
<li>See full diff in <a
href="https://github.com/github/gh-aw-actions/compare/v0.76.1...v0.77.0">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>
This updates the compare-stats anomaly reporter to retrieve benchmark
data from `http://mtzguido.tplinkdns.com:8081/z3/` instead of the old
`compare_stats.html` endpoint. The workflow prompt and generated lock
file now consistently reference the root benchmark stats URL.
- **Workflow source**
- Repoint the benchmark source URL from `.../compare_stats.html` to
`.../z3/`
- Update prompt text to describe the source as benchmark statistics
rather than a specific HTML file
- Rename the temporary fetched artifact from `compare_stats.html` to
`benchmark_stats.html` for consistency
- **Generated workflow**
- Regenerate `compare-stats-anomaly-reporter.lock.yml` so the compiled
workflow matches the markdown source
- Refresh the embedded workflow description and prompt payload to
reference the new endpoint
- **Report output**
- Update the discussion template’s source link to point at the root
benchmark stats page
```md
Source URL:
`http://mtzguido.tplinkdns.com:8081/z3/`
curl -fsSL --max-time 60 "http://mtzguido.tplinkdns.com:8081/z3/" \
-o /tmp/gh-aw/agent/benchmark_stats.html
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This adds an agentic workflow that analyzes `compare_stats.html` over a
rolling 30-hour window and publishes a GitHub Discussion summarizing
bugs, crashes, and anomalies. It explicitly captures unknown-outlier
patterns where a benchmark is `unknown` while peers in the same set are
mostly `sat`/`unsat`/`timeout`.
- **Workflow added**
- Introduces `.github/workflows/compare-stats-anomaly-reporter.md` (plus
compiled `.lock.yml`).
- Supports `workflow_dispatch` and scheduled execution.
- Uses safe discussion output with auto-close of older reports for the
same stream.
- **Data acquisition + robustness**
- Fetches `http://mtzguido.tplinkdns.com:8081/z3/compare_stats.html`
with `curl` and `wget` fallback.
- Adds integrity checks (non-empty HTML/table presence) and explicit
incomplete-report behavior on fetch/parse failures.
- **30-hour analysis semantics**
- Filters rows by timestamp candidates (`time`, `timestamp`, `date`,
`run`, etc.) using UTC.
- Falls back to full-table analysis when timestamps are unavailable, and
marks the report accordingly.
- **Classification logic**
- Detects bug/crash signals from status/details (`crash`, `segfault`,
`assert`, `abort`, `exception`, `error`, `failed`, `bug`).
- Detects:
- unknown-outlier anomalies (thresholded minority `unknown` in otherwise
decisive SAT-family outcomes),
- status divergences (conflicting non-timeout outcomes for same
benchmark),
- repeated hard-failure anomalies.
- **Discussion output shape**
- Produces a compact report with executive counts, bug/crash table,
anomaly subsections, and raw extraction summary/limitations.
```yaml
safe-outputs:
create-discussion:
title-prefix: "[Compare Stats] "
category: "agentic workflows"
close-older-discussions: true
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Monthly agentic workflow that discovers community-contributed SMT-LIB
benchmark repositories on GitHub, excluding official distributions from
smtlib.org and Zenodo, and posts a categorised summary as a GitHub
Discussion.
## Workflow steps
- **Exclusion list** — scrapes `smtlib.cs.uiowa.edu` + paginates the
[Zenodo SMT-LIB community](https://zenodo.org/communities/smt-lib/) (up
to 300 records) to extract official repo URLs; hard-excludes `SMT-LIB/*`
and `SMT-Competition/*` orgs
- **GitHub search** — 7 search strategies (topic tags
`smtlib`/`smt-lib`/`smt2`, filename/path patterns, README mentions)
scoped to repos pushed since the last run (90-day window on first run)
- **Filter + classify** — removes official sets and noise (homework
repos, empty repos); categorises survivors into: solver evaluation,
verification, security/CTF, theory/logic, tool output, education, other
- **Discussion report** — posts `[SMT-LIB Benchmarks] Community
Benchmark Repository Survey — [Month YYYY]`; older discussions
auto-closed after 90 days
- **Cache** — stores classified repo sets and run date so subsequent
runs are incremental
## Files
- `.github/workflows/smtlib-benchmark-finder.md` — workflow definition
- `.github/workflows/smtlib-benchmark-finder.lock.yml` — compiled GitHub
Actions YAML (`gh aw compile`)
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This updates the release and nightly pipelines so the Pyodide wheel is
built alongside the existing Python wheels and carried through the
normal publication flow. As a result, Pyodide wheels are included in
nightly assets and in release-time Python package publishing without
introducing a separate publishing path.
- **Pyodide build in release/nightly**
- Added a `pyodide-python` job to both `release.yml` and `nightly.yml`
- Reused the existing Pyodide build flow: install
`pyodide-build`/`pyodide-cli`, provision the matching Emscripten
toolchain, build the wheel, and run `z3test.py` against the built
artifact
- **Artifact integration**
- Upload the built wheel as a dedicated workflow artifact:
`PyodidePythonBuild`
- Extend the existing `python-package` aggregation job in both workflows
to depend on and download that artifact
- **Publication path**
- No new publish logic was added
- The existing downstream steps already publish everything collected in
`src/api/python/dist`, so the Pyodide wheel now flows into:
- nightly GitHub release assets
- release GitHub assets
- release-time PyPI publishing when enabled
```yaml
pyodide-python:
name: "Python bindings (Pyodide)"
...
- name: Upload artifact
uses: actions/upload-artifact@v7.0.1
with:
name: PyodidePythonBuild
path: src/api/python/dist/*.whl
python-package:
needs: [..., pyodide-python]
...
- name: Download Pyodide Build
uses: actions/download-artifact@v8.0.1
with:
name: PyodidePythonBuild
path: artifacts
```
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: NikolajBjorner <3085284+NikolajBjorner@users.noreply.github.com>
