Skip to content

release: 1.0.0-rc.4 - #270

Merged
mobileoverlord merged 1 commit into
mainfrom
rel/1.0.0-rc.4
Sep 15, 2026
Merged

mobileoverlord merged 1 commit into
mainfrom
rel/1.0.0-rc.4

Conversation

@mobileoverlord

Copy link
Copy Markdown
Contributor

What

Cut 1.0.0-rc.4: the [Unreleased] changelog section becomes ## [1.0.0-rc.4] - 2026-09-15, and the crate version moves from 1.0.0-rc.3 to 1.0.0-rc.4 in Cargo.toml and Cargo.lock.

Release notes

The rc.4 section of CHANGELOG.md is the release notes. It covers everything merged since rc.3, grouped Added / Changed / Fixed / Security:

Every bullet that was under [Unreleased] on main is present; entries for the PRs that landed without a changelog line were added. An empty [Unreleased] heading remains for the next cycle.

After merge

Tag the squash commit 1.0.0-rc.4 to run the release workflow. The first avocado build after upgrading reports every stamp as "stamp format changed (v4 → v5)" and rebuilds once.

Verification

fmt, clippy (-D warnings) and the full test suite pass on this branch; the version guard test reads 1.0.0-rc.4.

Promote the Unreleased changelog to 1.0.0-rc.4 (2026-09-15) and bump the
crate version in Cargo.toml and Cargo.lock.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The release metadata and changelog updates are consistent, with no unresolved review issues.

Pull request overview

Cuts the 1.0.0-rc.4 release by updating release notes and crate version metadata.

Changes:

  • Promotes unreleased notes to the dated rc.4 changelog.
  • Updates versions in Cargo.toml and Cargo.lock.
File summaries
File Description
CHANGELOG.md Adds rc.4 release notes and link
Cargo.toml Updates crate version
Cargo.lock Synchronizes locked package version
Review details
  • Files reviewed: 2/3 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@mobileoverlord
mobileoverlord merged commit 29d7b21 into main Sep 15, 2026
12 checks passed
@mobileoverlord
mobileoverlord deleted the rel/1.0.0-rc.4 branch September 15, 2026 20:45
mobileoverlord added a commit that referenced this pull request Sep 17, 2026
…276)

## Problem

The extension build legs never run the code in the pull request they are
gating.

`ext-test.yml` calls
`avocado-linux/actions/.github/workflows/extension-test.yml@v1`,
whose `setup-avocado-cli@v1` step downloads a **published GitHub release
asset**
(`cli-version` defaults to `latest`). The legs therefore check the
*shipped*
binary against the PR's extension config.

A regression on the extension path cannot fail in the PR that introduces
it. It
goes green under the previous release, ships, becomes `latest`, and then
fails
every unrelated PR that follows. That is exactly what #265 did:

| Event | Time (UTC) | Build legs |
| --- | --- | --- |
| #270, the 1.0.0-rc.4 release PR | Sep 15 20:00 | green, driven by rc.3
|
| 1.0.0-rc.4 published | Sep 15 20:51 | becomes `latest` |
| #271, #272, #274 | Sep 15 23:28 onward | red, driven by rc.4 |

The red is `Error: Failed to walk` with an empty path, the bug #274
fixes. Had
these legs run the PR's own binary, #265 would have failed on itself.

## Solution

Build the CLI from the PR source and drive the legs with it.

`cli` compiles it once and uploads it; the three `build` legs download
it and run
the same `sdk install` / `ext install` / `ext build` sequence as before.
Building
once rather than per leg is safe because this is a host tool: it is
identical for
every target and feed combination.

Other extension repos keep calling the reusable helper, which is right
for them.
They want the CLI their users run. This repo is the one that must not,
because it
is the CLI.

## Key changes

- `ext-test.yml` stops calling the reusable workflow and runs the
sequence itself
- A `cli` job builds `--release --locked` and shares the binary as an
artifact
- The artifact is re-chmodded on download: a zipped artifact does not
carry the
  executable bit
- It lands in `RUNNER_TEMP`, not the checkout, which is the project root
that
  `package_files` globs walk and `ext build` stages from
- The separate "Resolve version from Cargo.toml" job folds into the leg
that uses
  its value

## Reviewer notes

The in-container build runs `cargo build --target <triple>`, writing
`target/<triple>/release/`, so it cannot collide with the host build's
`target/release/`. They are also in different jobs on separate runners.

Check names change. The legs report as `Build <target> @
<release>/<channel>`
without the reusable workflow's `build (...) /` prefix. Neither ruleset
on `main`
requires any status check, so nothing needs updating alongside this.

The matrix, its three legs and the comments explaining them are
unchanged.

## Scope

The legs stay red until #274 lands. This change makes them run the right
binary;
it does not fix the bug they are currently reporting.

Two gaps this does not close, both worth their own issues:

- `avocado-ext-cli` is declared inline, so `ext_content_root` is `Some`
and the
package-sourced compile-script bug fixed in #271 still cannot reproduce
here.
Catching that class needs a fixture project with a `source: {type:
package}`
  extension.
- `ext-release.yml` packages the extension with the same published CLI
and is
  untouched here.

## Test

YAML parsed and the job graph, matrix and step list asserted locally.
The
extension name, the `avocado` bin target and the `[package] version`
read used by
the version step were each checked against the tree. CI on this PR is
the real
test: the legs must run the binary this PR builds, which `avocado
--version` in
the job log now shows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants