Fix build failure for course notes #2

Activity

1. andrewgait

   added the

   Task

   issue type on Aug 26, 2026
2. douglowe commented on Aug 27, 2026

   

   douglowe

   on Aug 27, 2026

   Member

   More actions

   Looks like some packages aren't installing properly - even though they do look to be downloaded.

   The following package(s) were not installed successfully:
   - [base64enc]: install failed
   - [rlang]: install failed
   - [yaml]: install failed

   base64enc 0.1-3
   rlang 1.1.5
   yaml 2.3.10
3. douglowe commented on Aug 27, 2026

   

   douglowe

   on Aug 27, 2026

   Member

   More actions

   I wonder if we shouldn't include the renv directory - see this repo for example setup: https://github.com/carpentries-incubator/python-intermediate-development
4. andrewgait commented on Sep 1, 2026

   

   andrewgait

   on Sep 1, 2026

   CollaboratorAuthor

   More actions

   I wonder if we shouldn't include the renv directory - see this repo for example setup: https://github.com/carpentries-incubator/python-intermediate-development

   Looks like that repo uses a different (set of) workflow(s) for building the course notes which are more recent than the ones we are using. It's probably worth updating our workflows to match.

   I think it is also the case that these workflows only work on the main branch so it's probably also worth changing to use main as default on our repositories too.
5. douglowe commented on Sep 3, 2026

   

   douglowe

   on Sep 3, 2026

   Member

   More actions

   Relevant to our interests, it looks like the Carpentries have just updated their build workflows - see this PR: carpentries-incubator/python-intermediate-development#541

   I am going to review this PR, get it merged in for that course, and then I'll see if we can take that build process for our repos here.
6. andrewgait commented on Sep 3, 2026

   

   andrewgait

   on Sep 3, 2026

   CollaboratorAuthor

   More actions

   Sounds good to me. Happy for you to create a main branch as part of that and merge everything there if that's necessary.
7. douglowe

   linked a pull request that will close this issueupdate to carpentry workflows from incubator example #3on Oct 2, 2026
8. andrewgait

   assigned

   douglowe

   on Oct 7, 2026
9. douglowe commented on Oct 9, 2026

   

   douglowe

   on Oct 9, 2026

   Member

   More actions

   @andrewgait & @dkfellows - I have built a test site in my personal git account, so we can see what potential damage there could be. Repository is here: https://github.com/douglowe/software-dev-python

   In the end I didn't edit any of the Carpentries workflows. What I did have to do is create a classic personal access token with the permissions 'public_repo, workflow'. This allows access to public repos and to update Github Action workflows.

   I think it's fine to allow access to public repos - but I am more cautious about having a token that allows the updating of workflows. What do you think?
10. andrewgait commented on Oct 9, 2026

    

    andrewgait

    on Oct 9, 2026

    CollaboratorAuthor

    More actions

    I would generally defer to @dkfellows on things like this, but I guess one question is whether the built-in GITHUB_TOKEN might work instead of a personal access token as described here? Or does that only work in the access case and not in the workflow case?
11. dkfellows commented on Oct 9, 2026

    

    dkfellows

    on Oct 9, 2026

    More actions

    First of all, I've no idea why the packages were failing to install. I've precisely zero experience with failure modes for R. (This isn't helped by the workflow logs having expired.) Sometimes, the detail in the log is critical in working out what went wrong. (And sometimes things just fail because the network inside Azure randomly decides "no bandwidth for you!" so there's that extra fun.)

    Secondly, there's three possible ways forward:

    1. Use a PAT and ensure it has the scopes you need.
    2. Use the standard GH token and grant it the permissions required.
    3. Use the token issuing bot. That has access to almost all permissions that GH knows about, but requires a more elaborate workflow.

    The workflow in question used the grant:

        permissions:
          checks: write
          contents: write
          pages: write

    but I don't know if that's sufficient for what it does. I'm guessing it's deploying sites by pushing to a gh-pages branch, which is the old way of doing it; there are more flexible approaches now. (Unfortunately, the way things are canned inside those R scripts, changing that to using a proper publish step is going to require much more work from someone who knows R...)
12. dkfellows commented on Oct 9, 2026

    

    dkfellows

    on Oct 9, 2026

    More actions

    @andrewgait If the permissions required are ones that you can grant to the GH token, that's actually the best approach as it declares everything very clearly and you can limit each job to have exactly the permissions it requires and no more (as well as the standard point that standard tokens are very short lived). The only real issue is that you can only grant a limited set of permissions (those directly associated with the repository), and that's very limited in some contexts (especially for forked repositories).

    And it's not always clear what permissions you need. 😀 The documentation is really quite confusing in this area. That's why our own actions repo has each action list what permissions are required (when it's not just contents: read); too much pain finding the info out otherwise. But others' actions and workflows? Often not properly characterised, alas.

    You are naturally encouraged to only supply the minimum permissions.
13. andrewgait commented on Oct 9, 2026

    

    andrewgait

    on Oct 9, 2026

    CollaboratorAuthor

    More actions

    So I think the answer is for @douglowe to do some testing of what permissions are required on the token in this instance; ideally using the GH token, but if that doesn't work then the personal access token will have to suffice.