Skip to content

Conversation

@erosselli
Copy link
Contributor

@erosselli erosselli commented Jan 2, 2026

Ticket []

Description Of Changes

This PR proposes a new way to create our release Changelog. Right now, it's very common to add your entry to the CHANGELOG.md file in a PR, and then have to constantly resolve conflicts on it as other PRs that also edited the file get merged. This PR proposes an entry-based approach, where each PR adds an entirely new file in a /changelog directory; the individual entries will get "compiled" into the CHANGELOG.md file as part of the release process via a nox script.

I think there's two benefits to this approach:

  • Since each PR will add its changelog entry as a new file, there should never be conflicts
  • Creating the changelog for a release no longer needs a person to manually edit the CHANGELOG.md file.

Code Changes

  • Added the /changelog directory with a TEMPLATE.yaml file that shows the format for the changelog entries
  • Added the nox -s changelog session (see more below)
  • Updated releases.md to reflect this new process
  • Updated the cursor command pr-command.md so that agents know how to create changelog entries
  • Adds a github action that checks if a changelog entry was added / changed and fails if not

Usage

nox -s "changelog(dry)" -> dry run of the command, will print to console the output that would be generated but will not make any changes

nox -s "changelog(write)" -- --release 2.77.0 -> will generate the changelog for the provided release version from the entries in the /changelog directory . This will also delete the entries from the /changelog directory.

nox -s "changelog(write)" -- --release 2.76.2 --prs 1234,5678 -> will only compile the entries for the given PRs into the CHANGELOG.md file, leaving the rest as-is. This is useful for patch releases where only some commits will get released.

Pre-Merge Checklist

  • Issue requirements met
  • All CI pipelines succeeded
  • CHANGELOG.md updated
    • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
    • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
    • Updates unreleased work already in Changelog, no new entry necessary
  • UX feedback:
    • All UX related changes have been reviewed by a designer
    • No UX review needed
  • Followup issues:
    • Followup issues created
    • No followup issues
  • Database migrations:
    • Ensure that your downrev is up to date with the latest revision on main
    • Ensure that your downgrade() migration is correct and works
      • If a downgrade migration is not possible for this change, please call this out in the PR description!
    • No migrations
  • Documentation:
    • Documentation complete, PR opened in fidesdocs
    • Documentation issue created in fidesdocs
    • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
    • No documentation updates required

@vercel
Copy link

vercel bot commented Jan 2, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Review Updated (UTC)
fides-plus-nightly Ignored Ignored Preview Jan 6, 2026 2:20pm
fides-privacy-center Ignored Ignored Jan 6, 2026 2:20pm

@codecov
Copy link

codecov bot commented Jan 2, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.24%. Comparing base (cfbf98a) to head (d215ece).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #7177      +/-   ##
==========================================
+ Coverage   87.17%   87.24%   +0.06%     
==========================================
  Files         535      535              
  Lines       35330    35335       +5     
  Branches     4113     4114       +1     
==========================================
+ Hits        30800    30828      +28     
+ Misses       3639     3617      -22     
+ Partials      891      890       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@erosselli erosselli marked this pull request as ready for review January 5, 2026 12:37
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Jan 5, 2026

Greptile Summary

Introduces a fragment-based changelog system to eliminate merge conflicts when multiple PRs edit CHANGELOG.md. Each PR now adds a YAML file in the changelog/ directory instead of editing the changelog directly. A nox script (nox -s changelog) compiles these fragments during the release process.

  • Added noxfiles/changelog_nox.py with changelog(dry) and changelog(write) sessions for compiling fragments
  • Added GitHub workflow to verify PRs include changelog entries
  • Updated release documentation with the new workflow
  • Updated Cursor PR creation command to generate changelog fragments

Issue Found: The code validates pr as a required field, but documentation states it's optional. This will cause runtime errors when users follow the documented optional behavior.

Confidence Score: 3/5

  • PR introduces useful developer tooling but has a documentation/code mismatch that will cause confusion
  • Score of 3 reflects solid implementation with one logic inconsistency: the pr field is validated as required in code but documented as optional in multiple places, which will cause errors when users follow the documentation
  • noxfiles/changelog_nox.py (pr field validation), docs/fides/docs/development/releases.md (documentation consistency)

Important Files Changed

Filename Overview
noxfiles/changelog_nox.py Core changelog compilation script with well-structured code. Found one logic inconsistency: pr field is validated as required but documented as optional.
.github/workflows/check_changelog.yml GitHub workflow to check for changelog entries on PRs. Correctly filters out template files and handles YAML extensions.
docs/fides/docs/development/releases.md Updated release documentation with new changelog fragment workflow. Documents pr as optional but code requires it.
.cursor/commands/pr-create.md Updated Cursor command to create changelog fragments instead of editing CHANGELOG.md directly.
changelog/TEMPLATE.yaml Template file for changelog fragments with correct structure and documented type options.
changelog/README.md Documentation for the changelog fragment system with usage examples.

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

9 files reviewed, 4 comments

Edit Code Review Agent Settings | Greptile

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
@erosselli
Copy link
Contributor Author

@greptile

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

9 files reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

Comment on lines 87 to 88
if "pr" not in data:
missing.append("pr")
Copy link
Contributor

Choose a reason for hiding this comment

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

I didn't see a check to verify the PR number etc is added before merging. Its not a huge issue, just kind of a gap. The change could be added to the changelog without a PR # or link.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe in the workflow file we could add something like this to catch any errors at PR time instead of release time.

- name: Validate changelog entries
  run: |
    pip install pyyaml
    nox -s "changelog(dry)"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a nox -s "changelog(validate)" that allows specifying only specific files

Copy link
Contributor

@JadeCara JadeCara left a comment

Choose a reason for hiding this comment

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

Left a comment on a potential gap, other than that looks good to me. The commands ran as expected!

Thanks for the excellent updates to the documentation!

Co-authored-by: Jason Gill <jason.gill@ethyca.com>
- In the description and code changes sections, do not include information about code formatting or general code clean up changes.
- Do not include running tests as part of the Steps to Confirm, those will run automatically as part of the PR.
- The issue can usually be derived from the current branch name, it's a Jira ticket with prefix "ENG-" (eg. `Ticket [ENG-1234]`)
- If `acli` is available, use `acli jira workitem view [key]` cli command to get more information about the issue.
Copy link
Contributor

Choose a reason for hiding this comment

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

sorry, this one needs it also:
"Full permissions must be used for the acli credentials to work, even when in sandbox mode."

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.

4 participants