Repository navigation
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8f325c673
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| export const releaseVersion = "0.8.0"; | ||
| export const releaseInstallCommand = `python3 -m pip install ${repoUrl}/releases/download/v${releaseVersion}/dotmatch-${releaseVersion}.tar.gz`; |
There was a problem hiding this comment.
When this commit reaches main while docs/distribution-release.json still marks 0.8.0 as prepared_not_published, the Pages workflow builds and deploys unconditionally, so the primary install command points every visitor at a release asset that does not yet exist. The new DOTMATCH_REQUIRE_PUBLISHED_GITHUB check is not enabled in .github/workflows/pages.yml; gate that deployment on the verified release record or continue advertising 0.7.0 until publication succeeds.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed: the 0.8.0 distribution record is prepared_not_published while the public install command advertises its release asset. The existing release hold remains. Production build/publication must require a verified matching release record, or advertising must remain on the published release. No GitHub Actions workflows were changed or used.
| def _sibling(path: Path, suffix: str = '') -> Path: | ||
| descriptor, name = tempfile.mkstemp(prefix='.dotmatch-', suffix=suffix, dir=path.parent) | ||
| os.close(descriptor) |
There was a problem hiding this comment.
For Python counting and write_assignments_tsv, mkstemp() creates every staged file with mode 0600, and the later os.replace() publishes that mode unchanged. Consequently, even a successful rerun of an existing 0644/group-readable result silently makes it owner-only, breaking downstream jobs that read results under another account; the previous direct file open preserved an existing destination's mode and used the normal umask for new files.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed: mkstemp stages publish 0600 and can remove existing group/public readability. Prepared public count/assignment regressions for existing 0640 files and new files under umask 027, but the wrapped test attempts deferred before execution. This remains open alongside the documented rollback/in-place-edit release blocker.
This branch has not been deployed
2 participants
Problem and result
Failed counts could truncate inputs or earlier assignment files. Python detailed count tables could also be imported as several samples by counting correction components separately.
This candidate stages native and Python count artifacts, rejects aliased destinations, checks stream completion, and recovers prior results after ordinary publication failures. Python
count_totalimports as one sample. Assay projects gain an offline setup review, reliability reports put the recorded verdict and actions first, and the installedsensitivity-reviewcommand exposes the existing checked renderer.Scope and tradeoffs
The 0.8.0 candidate covers the CLI, Python interface, offline reports and website source. The intended publication is a GitHub source distribution and verified Linux x86_64 wheel. PyPI and GHCR remain at their verified 0.7.0 versions. Native Apple, other architectures and public website deployment require separate acceptance.
Each file replacement is atomic. The output set is not crash-atomic. Existing-file recovery uses sibling hardlinks and reports retained backups when recovery cannot complete.
Evidence
Source HEAD
c8f325c6736556305f9e5b63e861a99d286dedf6. Intended main base4809f5c2bc3ad83d90a3df85e10515b1f0223dcb.Outstanding release blocker
Independent source review identified a remaining P1 in native and Python rollback. Recovery checks the published inode identity only. A concurrent in-place edit preserves that identity, so a later publication failure can restore or delete over the external edit. Recovery must compare a saved complete published version and retain the prior-file backup when that version changes. A public Python regression has been prepared outside the committed revision; its attempted reproduction was deferred by resource admission. The corresponding native failure-injection hook already exists. This finding is source-derived and is not claimed reproduced or fixed.
Release hold: keep this PR unmerged and unpublished until the rollback finding is resolved, required current local gates pass, and independent exact-revision real-surface verification approves the intended destination. No merge or release has been armed.