Skip to content

Restore ISSUE_BODY to github output - #74

Merged
keewis merged 1 commit into
scientific-python:mainfrom
li-em:li-em/restore_issue_body
Jul 24, 2026
Merged

Restore ISSUE_BODY to github output#74
keewis merged 1 commit into
scientific-python:mainfrom
li-em:li-em/restore_issue_body

Conversation

@li-em

@li-em li-em commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

I think #66 dropped echo "ISSUE_BODY=$ISSUE_BODY" >> $GITHUB_OUTPUT and now the issue body is not being generated anymore. This PR restores the dropped line.

@keewis

keewis commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

good catch! That was a bad merge (I hope), because I do remember I verified it worked in #67.

I guess a test suite would have helped in this case to avoid this, but I'll have to think of a way to avoid needing to mutate a repository. A dry-run option maybe? Either way, thanks for the fix.

@keewis
keewis merged commit 054799b into scientific-python:main Jul 24, 2026
5 checks passed
@li-em
li-em deleted the li-em/restore_issue_body branch July 24, 2026 13:20
DahnJ pushed a commit to DahnJ/icechunk that referenced this pull request Jul 24, 2026
…eam GHA (earth-mover#2294)

Couple of different problems detected in earth-mover#1921 fixed on this PR:

-
[scientific-python/issue-from-pytest-log-action](scientific-python/issue-from-pytest-log-action#74)
was not uploading the issue body anymore, fixed upstream, bumped version
here.

- earth-mover#2175 removed our zarr tests overrides, but that leaves us in an
inconsistent state while zarr 3.3 (or the current `main`) is not
released, and we bump our minimum supported zarr. Opted to checking if
the `_get_*` exist instead of a version range check, and we can actually
drop the overrides once we move newer zarr releases

## stateful testing fixes

- `test_zarr/test_stateful.py`: use the storage-key chunk grid in
`shift_array`. The rule used `cdata_shape`, which counts *inner* chunks
for sharded arrays, while store keys and `Session.shift_array` operate
on the outer (shard) grid. zarr main's hypothesis strategies now
generate sharded arrays, exposing this: the model shuffled keys over a
grid that doesn't exist (e.g. producing `0/c/1` for a single-shard
array). A new `storage_chunk_sizes` helper uses zarr's
`write_chunk_sizes` when available and derives the grid from `shards or
chunks` on older zarr. Includes deterministic regression tests, verified
against both zarr 3.1.6 and zarr nightly.

- `test_stateful_repo_ops.py`: match the model's GC re-parenting to
Rust. The model re-parented kept snapshots whose parent was GC'd to the
*initial* snapshot, but `delete_snapshots_from_repo_info` re-parents
over the deleted run to the *nearest surviving ancestor*. After a
`reset_branch` back onto such a snapshot, model and repo disagreed on
reachability, and the next `garbage_collect` predicted the wrong
`snapshots_deleted` count. Triggered only when a GC deletes a middle run
while older (ref-pointed) and newer (`flushed_at`-protected) snapshots
both survive — hence the intermittent nightly appearances.

- `test_stateful_repo_ops.py`: guard `create_branch`/`create_tag`
against V1 expired-ancestor chains. V1 expiration rewrites only
ref-reachable chains, so an unreachable commit's on-disk ancestry can
still pass through expired snapshots the model dropped; creating a ref
there resurrects history the model no longer tracks and fails
`check_ancestry`. Applies the same full-ancestry `assume()` that
`reset_branch` already uses.
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.

2 participants