Skip to content
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.

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

[BUG] pkgdown site build fails within Docker containers #29

Closed
bschilder opened this issue Apr 26, 2022 · 7 comments
Closed

[BUG] pkgdown site build fails within Docker containers #29

bschilder opened this issue Apr 26, 2022 · 7 comments
Assignees

Comments

@bschilder
Copy link

bschilder commented Apr 26, 2022

pkgdown site step runs into error when using a Docker container.

Issue

This happens because of the recent changes to git regarding security.

Supposedly this has been fixed in regards to some GH actions, but apparently not all. The suggested workaround doesn't work as-is and needs some adjusting:

Screenshot 2022-04-26 at 11 42 50

Solution

I've implement this in my adapted version of Biocthis's GHA workflow, seen here. In the case of my echodata R package, this solution seems to work well.

This involves an extra GHA step beforehand that extracts the R package name from the DESCRIPTION file. This is more robust than assuming that the repository has an identical name as the package itself, which is sometimes not the case due to differences in capitalization or use of "." vs "_". You can see this step here:
https://github.com/RajLabMSSM/echodata/blob/3d4544341de35f9a43fec661671d87515cb7be42/.github/workflows/check-bioc-docker.yml#L325

Other notes

Doesn't seem like Biocthis's GHA checks for itself are catching this error; do you run any GHA within a Docker container? If not, this would be quite helpful to have as it would ensure your workflow templates are running as expected both within and outside of containers.

Best,
Brian

@lcolladotor lcolladotor self-assigned this Apr 26, 2022
@lcolladotor
Copy link
Owner

Thanks for the report Brian! I'll look into it later this week. I'm a bit out of the loop on the Git security changes, so thanks for the link to actions/checkout#760.

I've encountered some git issues like at lcolladotor/team_surveys@5fe88a9 or the one you described (at https://github.com/LieberInstitute/spatialLIBD/runs/6114315548?check_suite_focus=true#step:28:27 in my case), which I simply dodged by disabling pkgdown since I didn't have time to deal with it then.

@bschilder
Copy link
Author

Sounds good, let me know if you have any questions then.

@kevinrue
Copy link
Contributor

kevinrue commented Jun 1, 2022

Hi there

I've added a couple of hot fixes in my own repository

Namely:

  • I incremented checkout to version 3, which claims to resolve the issue.
  • Unfortunately the issue remained for me, so I added a step that runs the command suggested by the error message. I've seen some messages about running it from outside the repository, hence the cd but I did not check myself whether that was essential or not. At least it works now.
      - name: Checkout Repository
        uses: actions/checkout@v3

      ## fatal: unsafe repository ('/__w/iSEE/iSEE' is owned by someone else)
      ## see: https://github.com/actions/checkout/issues/760
      - name: Fix Git permission
        run: |
          cd $HOME
          git config --global --add safe.directory /__w/iSEE/iSEE

Notes:

  • Replace iSEE/iSEE by your own username/repository

The issue is being fixed by the authors of the checkout github action. So the hot fix above might be irrelevant relatively soon. I've already seen two issues on their repository that are closed and claim to fix it, but for some reason, simply upgrading the checkout version was not enough for me.

@milanmlft
Copy link
Contributor

Hi all, I encountered this issue as well. After some exploration, noticed the r-lib folks simplified their pkgdown example:
r-lib/actions@ebeab6d

Notice the use of pkgdown::build_site_github_pages(), which is a relatively new function I think?
They also separated the build and deployment steps, which has some benefits for CI (see discussion here: r-lib/actions#468).

I'm using this approach in my current actions and it works fine. Also seems easier to maintain :)
Would be happy to update the current biocthis templates with a PR if desired.

@kevinrue
Copy link
Contributor

I've just noted something more that is visible in the screenshot at the top of this thread:
The two git config commands:

  git config --local user.name "$GITHUB_ACTOR"
  git config --local user.email "$GITHUB_ACTOR@users.noreply.github.com"

fail because they're run from the home directory (one level up from the git repo.

The errors (visible in the screenshot too) are

fatal: --local can only be used inside a git repository
fatal: --local can only be used inside a git repository

I'm not sure why those lines were not an issue before, but it sounds like the fix is either to cd into the subdirectory of the repo, or use --global instead

@lcolladotor
Copy link
Owner

FYI I've been away most of June as my father had an important surgery. I'll be back in the office on July 5th.

lcolladotor added a commit that referenced this issue Oct 31, 2022
…at #29. Now also related to #31 since this brings into the play JamesIves/github-pages-deploy-action@releases/v4
@lcolladotor
Copy link
Owner

Thanks everyone for this thread! This works again as you can see at https://github.com/lcolladotor/biocthis/actions/runs/3364123000/jobs/5578109324#step:30:90 ^^

I tried adapting some of https://github.com/r-lib/actions/blob/465e3c76cf4d432b547a0a411972939899c87857/examples/pkgdown.yaml#L40-L46 as suggested by you earlier, but also using JamesIves/github-pages-deploy-action@releases/v4 (see #31 by @lmweber) instead of the specific version 4.4.1 at https://github.com/r-lib/actions/blob/465e3c76cf4d432b547a0a411972939899c87857/examples/pkgdown.yaml#L42. I had to add the installation of rsync as a system dependency to make this work.

It thus comes down to

- name: Install package
if: github.ref == 'refs/heads/{{pkgdown_covr_branch}}' && env.run_pkgdown == 'true' && runner.os == 'Linux'
run: R CMD INSTALL .
- name: Build pkgdown site
if: github.ref == 'refs/heads/{{pkgdown_covr_branch}}' && env.run_pkgdown == 'true' && runner.os == 'Linux'
run: pkgdown::build_site_github_pages(new_process = FALSE, install = FALSE)
shell: Rscript {0}
## Note that you need to run pkgdown::deploy_to_branch(new_process = FALSE)
## at least one locally before this will work. This creates the gh-pages
## branch (erasing anything you haven't version controlled!) and
## makes the git history recognizable by pkgdown.
- name: Install deploy dependencies
if: github.ref == 'refs/heads/{{pkgdown_covr_branch}}' && env.run_pkgdown == 'true' && runner.os == 'Linux'
run: |
apt-get update && apt-get -y install rsync
- name: Deploy pkgdown site to GitHub pages 🚀
if: github.ref == 'refs/heads/{{pkgdown_covr_branch}}' && env.run_pkgdown == 'true' && runner.os == 'Linux'
uses: JamesIves/github-pages-deploy-action@releases/v4
with:
clean: false
branch: gh-pages
folder: docs
in addition to using checkout@v3.

I saw that @kevinrue and @dzhang32 have a solution without using pkgdown::build_site_github_pages() (aka, still using pkgdown::deploy_to_branch(new_process = FALSE)). @kevinrue has it hardcoded while @dzhang32 adapted a solution by @RajLabMSSM that creates an environmental variable to determine the package name. This could have been done with the template utilities. But well, I thought it would be best to stay as close as possible to r-lib/actionsexamples/pkgdown.

I did note the use of https://github.com/r-lib/actions/blob/465e3c76cf4d432b547a0a411972939899c87857/examples/pkgdown.yaml#L31-L34 which is documented at https://github.com/r-lib/actions/tree/v2-branch/setup-r-dependencies, however, I thought it was simpler to only install rsync, given that we are building on top of the Bioconductor docker image and already have lots installed.

Best,
Leo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants