docs: remove generated API reference files from git tracking#5156
Merged
timdeschryver merged 5 commits intoMay 20, 2026
Conversation
Add a dedicated GitHub Actions workflow that runs the collect-docs task weekly (every Sunday at midnight UTC) and on manual trigger. The workflow builds all NgRx modules, runs the collect-docs script to regenerate API reference JSON files, and commits any changes back to main using '[skip ci]' to avoid infinite loops. Closes #5154 Co-authored-by: Copilot <[email protected]>
Update the collect-docs workflow to create/update a pull request instead of committing directly to main. Co-authored-by: Copilot <[email protected]>
Replace the create-pull-request action in the collect-docs workflow with gh CLI commands that create or update the docs PR. Co-authored-by: Copilot <[email protected]>
- Fix early-exit check to use git diff --cached after staging files so new (untracked) reference JSON files are also detected - Fix concurrency group to use workflow name only so scheduled runs correctly cancel duplicate in-flight runs - Remove unnecessary fetch-depth: 0 Co-authored-by: Copilot <[email protected]>
✅ Deploy Preview for ngrx-io ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
timdeschryver
changed the title
Member
|
@timdeschryver do we need this? It seems that I think we can just remove generated API docs from the repo, add to |
Member
Author
|
@markostanimirovic it seems that you're right! I saw the files and assumed they had to be part of the repo, but reading your comment about it being a part of the build process makes more sense, and it works. |
The collect-docs task already runs as part of the www build (declared in dependsOn), so the reference JSON files are regenerated on every build. There is no need to commit them to the repository. The .gitignore entry for these files already existed; this commit simply untracks the 334 JSON files that were previously committed. Fixes: #5154 Co-authored-by: Copilot <[email protected]>
timdeschryver
changed the title
Member
Author
|
It appears it was a left-over, |
markostanimirovic
approved these changes
May 19, 2026
rainerhahnekamp
approved these changes
May 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The 334 generated API reference JSON files under
projects/www/src/app/reference/are committed to the repository. This means they can go stale whenever the API surface changes, requiring a manual run ofcollect-docsto update them.Fixes: #5154
What is the new behavior?
The generated files are untracked. The
.gitignoreentry for them already existed; this PR removes the previously committed copies.The
collect-docstask already runs automatically as part of thewwwbuild viadependsOn, so the files are regenerated fresh on every website build. There is no need to store them in the repo.Does this PR introduce a breaking change?
Other information
N/A