8000 Adding new sections to AnalysisBook breaks the build · Issue #33 · teorth/analysis · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Adding new sections to AnalysisBook breaks the build #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
teorth opened this issue Jun 9, 2025 · 4 comments
Open

Adding new sections to AnalysisBook breaks the build #33

teorth opened this issue Jun 9, 2025 · 4 comments

Comments

@teorth
Copy link
Owner
teorth commented Jun 9, 2025

I tried naively adding a new section to AnalysisBook in 90201e7#diff-8c94bd1d7883c9c05fc3bd2cb50e697cced3cbaf94289a7e3942be26e93b91e3 but it did not pass CI (according to https://github.com/teorth/analysis/actions/runs/15536415550/job/43736438185 , the lines added caused some sort of heartbeat error). I then removed the offending lines in b90c85c and the CI worked again.

(Separately, I am trying to figure out how to protect the repository from my own force pushes breaking the build, but have not yet figured out exactly how to do so.)

What is a safer procedure to add new sections to AnalysisBook?
@hansonchar
Copy link
Contributor

I presume you'd have done a successful build locally before pushing. If so, why would it break the build. If not, why not?

@pimotte
Copy link
Contributor
pimotte commented Jun 9, 2025 •
edited
Loading

The heartbeat error we should be able to address by adding set_option maxHeartbeats <high number> before the def_literate_page line. That being said, the underlying issue here is that this def_literate_page construct is very computationally heavy, which I want to ask David about when he's back from leave (which should be tomorrow).

Some generic recommendations for safety with the build:

  • Don't force push (not in general, but especially not on main). If git rejects your push, first pull (which merges the remote changes in your local branch) and then push again.
  • Work along the same workflow that external contributors go through to let the CI build before merging.

What I do:

git checkout main
git pull
git checkout -b feature/new
# make commits to create new feature
git push -u origin feature/new

Then make a pull request, and wait for the CI to finish before merging.

@hansonchar
Copy link
Contributor
hansonchar commented Jun 9, 2025 •
edited
Loading

I'd recommend pulling with rebase to keep a clean and linear history:

git pull --rebase

This also helps avoid the need for a force push in the first place. (I was wondering why you needed to force push — I’m guessing you didn’t use rebase but merged instead. In general, force pushes should be used sparingly.)

@teorth
Copy link
Owner Author
teorth commented Jun 9, 2025

I think I managed to install a ruleset on the default branch that requires a PR before merging even for myself, we'll see how that goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@teorth @hansonchar @pimotte
0