I am having two issues here, the first can be solved but there is no point if the second cannot.
The first is that the action requires an access token to be allowed to make a commit.
The second is that running all notebooks takes too long. Splitting them up into one action per notebook isn't possible (at least not straightforwardly and without hard coding the notebook names), and doing only those that have changed may be possible but I don't see a great way of determining that (what to compare to, the second to last commit, the main branch, etc, I don't think there's a choice that will always make sense).
So I would say to put this on hold unless someone has an idea how to deal with the second issue.
The good news is that we should just be able to do it manually with the workflow:
make changes to the source of a notebook
commit them, pre-commit will overwrite the notebook with an unevaluated but up to date notebook
if we want the output to be visible in the notebook, just run manually and commit separately
the precommit only triggers when the source is changed, so it won't interfere in the last step.
It's maybe not ideal, but good enough I guess, especially considering that we'll also have notebooks that have to run on the GPU for which we need to do this anyway.
The precommit will only guarantee that notebooks are up to date with their source, but if any of the code in the package that it depends on changes (which doesn't change the unevaluated notebook but can cause changes in the results), they are not updated. So if we want to be careful, we have to run all notebooks manually as a last commit before merging any PR.
I am having two issues here, the first can be solved but there is no point if the second cannot.
The first is that the action requires an access token to be allowed to make a commit.
The second is that running all notebooks takes too long. Splitting them up into one action per notebook isn't possible (at least not straightforwardly and without hard coding the notebook names), and doing only those that have changed may be possible but I don't see a great way of determining that (what to compare to, the second to last commit, the main branch, etc, I don't think there's a choice that will always make sense).
So I would say to put this on hold unless someone has an idea how to deal with the second issue.
The good news is that we should just be able to do it manually with the workflow:
the precommit only triggers when the source is changed, so it won't interfere in the last step.
It's maybe not ideal, but good enough I guess, especially considering that we'll also have notebooks that have to run on the GPU for which we need to do this anyway.
The precommit will only guarantee that notebooks are up to date with their source, but if any of the code in the package that it depends on changes (which doesn't change the unevaluated notebook but can cause changes in the results), they are not updated. So if we want to be careful, we have to run all notebooks manually as a last commit before merging any PR.