Skip to content

chore: release main#27

Merged
znat merged 1 commit intomainfrom
release-please--branches--main
May 4, 2026
Merged

chore: release main#27
znat merged 1 commit intomainfrom
release-please--branches--main

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions Bot commented May 4, 2026

🤖 I have created a release beep boop

0.1.0

0.1.0 (2026-05-04)

Features

  • Open PR detail in a right-side drawer with scroll preserve (#25) (0a31f0f)
  • Redesign PR detail page (port from gitsky) (#24) (32a2f7d)
  • ship @gitpulse/cli + reusable Pages workflow (#26) (44c95b0)

Bug Fixes

  • populate first-release editions and simplify URL (#22) (762cd86)
0.1.1

0.1.1 (2026-05-04)

Features

  • ship @gitpulse/cli + reusable Pages workflow (#26) (44c95b0)

This PR was generated with Release Please. See documentation.

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 4, 2026

Greptile Summary

Auto-generated Release Please PR bumping @gitpulse/cli from 0.1.0 to 0.1.1, adding the root CHANGELOG.md entry for the 0.1.0 main-package release, and creating cli/CHANGELOG.md for the CLI sub-package. The only notable issue is a self-referential comparison URL (v0.1.0...v0.1.0) in CHANGELOG.md, a known Release Please quirk for first-ever releases.

Confidence Score: 4/5

Safe to merge — only a P2 documentation quirk, no code logic is changed.

All changes are auto-generated release artifacts (manifest, changelogs, package version). The sole finding is a self-referential comparison URL in CHANGELOG.md, which is a cosmetic/documentation P2 introduced by Release Please's handling of first releases. No runtime code is affected.

CHANGELOG.md — broken comparison URL, though this is a known Release Please limitation and not a blocker.

Important Files Changed

Filename Overview
.release-please-manifest.json Bumps the cli package version from 0.1.0 to 0.1.1, consistent with the rest of the release.
CHANGELOG.md Prepends the 0.1.0 release block; the comparison URL v0.1.0...v0.1.0 is self-referential (known Release Please first-release quirk) and will show an empty diff on GitHub.
cli/CHANGELOG.md New changelog file for @gitpulse/cli; documents the 0.1.1 release with its single feature entry and a correct v0.1.0...v0.1.1 comparison URL.
cli/package.json Version bumped from 0.1.0 to 0.1.1, aligned with the manifest and changelog.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Release Please Bot] --> B[Bump cli/package.json\n0.1.0 → 0.1.1]
    A --> C[Update .release-please-manifest.json\ncli: 0.1.0 → 0.1.1]
    A --> D[Prepend 0.1.0 block to CHANGELOG.md]
    A --> E[Create cli/CHANGELOG.md\nv0.1.0 → v0.1.1]
    D --> F[⚠️ Self-referential URL\ncompare/v0.1.0...v0.1.0\nshows empty diff on GitHub]
    E --> G[✅ Correct comparison URL\ncompare/v0.1.0...v0.1.1]
Loading

Fix All in Claude Code

Reviews (1): Last reviewed commit: "chore: release main" | Re-trigger Greptile

Comment thread CHANGELOG.md
@@ -1,5 +1,19 @@
# Changelog

## [0.1.0](https://github.com/znat/gitpulse/compare/v0.1.0...v0.1.0) (2026-05-04)
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Self-referential comparison URL for first release

The comparison link compare/v0.1.0...v0.1.0 points to the same ref on both sides, so it will always render as an empty diff on GitHub. For a first-ever release there is no earlier tag to compare against — Release Please is known to generate this incorrect URL in that case. The link should ideally point to the tag itself (e.g. releases/tag/v0.1.0) or be omitted.

Fix in Claude Code

@znat znat merged commit 5d65758 into main May 4, 2026
znat added a commit that referenced this pull request May 4, 2026
The release-please run after merging #27 failed because of a duplicate-tag
collision: the root package's "release-as": "0.1.0" pin combined with the
linked-versions plugin made both packages target tag v0.1.0, which already
existed from a prior manual release. Result: GH release creation failed,
no v0.1.1 tag was created, no npm publish happened — but the manifest got
bumped to cli: 0.1.1 and PR #27's label flipped to autorelease: tagged.

Rolling back the half-applied state so release-please can compute the
release fresh on its next run:

- cli/package.json: 0.1.1 → 0.1.0 (the bumped version was never tagged
  or published, so reverting is safe).
- .release-please-manifest.json: cli back to 0.1.0.
- cli/CHANGELOG.md: deleted (was just created with a 0.1.1 entry that
  never shipped; release-please will recreate on next release).
- CHANGELOG.md: removed the bogus duplicate "0.1.0" header
  release-please added with the broken compare/v0.1.0...v0.1.0 link.
- release-please-config.json: removed "release-as": "0.1.0" from the
  root package — it was the original cause of the collision and is no
  longer needed (root is already at 0.1.0).

Next push triggers release-please. With the pin gone and linked-versions
in place, both packages will compute to 0.1.1, the v0.1.1 tag is fresh,
and the publish-cli OIDC pipeline runs end-to-end.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant