Conversation
|
Hi @g-samroberts, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this. We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines. Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed. Thank you for your understanding and for being a part of our community! |
|
Hi there! Thank you for your contribution to Gemini CLI. To improve our contribution process and better track changes, we now require all pull requests to be associated with an existing issue, as announced in our recent discussion and as detailed in our CONTRIBUTING.md. This pull request is being closed because it is not currently linked to an issue. Once you have updated the description of this PR to link an issue (e.g., by adding How to link an issue: Thank you for your understanding and for being a part of our community! |
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
|
Size Change: -4 B (0%) Total Size: 26.2 MB ℹ️ View Unchanged
|
jerop
left a comment
There was a problem hiding this comment.
also if a changelog PR is opened after a patch, it'll be useful to link the PR to the patched PR so that maintainers remember to review and merge it - something like this: #21713 (comment)
|
@jerop That would be helpful in tracking + merging the changelog update, but this workflow is triggered by the release event as opposed to a dispatch like the workflow that creates the patch comments. I'm not sure the patch PR would be available to this workflow... any ideas? This could be a good area for future improvement. For now my aim was to tie it to the Docs tracking issue so it transitively gets the TW project applied, which means it shows up on our PR tracking list. Let me know your thoughts! |
Summary
Add issue for automated changelogs, so they show up on our project board. Currently automatically generated changelog PRs don't have an issue tied to them, and can get lost in the PR mix.
With this change, changelogs will link to #18505. This way the auto triage both will transitively apply the area/documentation label and put the PR in Technical Writer project, so it appears on our PR review list. This is the main changelog issue, this also serves to put all changelog PRs under one issue for easier search/development.
Note that this is different from the issue that engineering might use to track the release that results in the changelog.
Related to #18505