R/Pharma website

• Urgent to-do
• General framework
• Call to action
• gsheet as source of truth
  • Accessing the data (e.g. for shiny apps)
  • proceedings
  • team
  • conference schedules
• Deploying the site
  • When deployments are triggered
  • As a contributor
  • Details on how deploy.yml works

Final: R/Pharma website: rinpharma.com

Urgent to-do

Schedules look terrible

The files layouts/partials/rinpharmaXXXX.html need editing (along with CSS added) to improve the look of the conference specific schedules.

Schedules data management is clunky

Currently we have a separate layout for each conference, as I couldn’t figure out yet in Hugo how to pass down which data file to use. This must be possible though - so will need to dive deeper into shortcodes and partials in Hugo to see how to do it.

Add in build_scripts to deploy.yml

Quick thing to add - but waiting till I sort out the general look so I don’t needlessly keep hitting Google’s API.

General framework

This website is based on the Hugo theme starter-research-group, a fork off the academic theme. The theme documentation is shared - and available at wowchemy.com/docs/.

Call to action

The 'call to action' (cta) is the button that tells people to signup for the next conference. Enable or disable in the file content/home/welcome.md.

gsheet as source of truth

We use this gsheet as a source of truth for the proceedings (abstracts of talks) and the list of organisers. This gsheet is read by the Github action .github/workflows/deploy.yml when it rebuilds and deploys the site.

The folders content/authors/ and content/publications/ are built in the CICD process - so editing them in the site code has no effect. You must edit the gsheet.

The CICD process also build the rinpharmaXXXX .yml files in data/ that have the schedule data for each conference.

Important

Please make sure to update the gdoc if you want to edit the proceedings, schedule or list of people.

Accessing the data (e.g. for shiny apps)

The gsheet data (minus information people might not want shared like emails) is written to a public Rstudio 'pins' dataset, which can be accessed by other services (e.g. a conference specific shiny app), or to do something like a wordcloud on abstracts.

The data is in this repo github.com/rinpharma/rinpharma-data, and is written to by the CICD process. You can access it (with no authentication) via the following code.

library(pins)
board_register_github(repo = "rinpharma/rinpharma-data",branch = "master")
pin_get("proceedings", board = "github")

proceedings

The sheet all_conferences in the main gsheet is used to populate the proceedings on the site. The CICD process takes the gsheet data and makes an entry in publication/ for each talk from the conference.

team

The sheet team in the main gsheet is used to populate the people section on the site. The CICD process takes the gsheet data and makes an entry in authors/ for each person. We can update the R code in build_scripts to allow multiple groups here.

Note

The script build_scripts/build_profile_image.R looks in the gravatar and libravatar profile image services for your public profile photo. If you want to add your photo - please use either service to link you email to a profile image. libravatar is an open source take on gravatar. Links; gravatar and libravatar

conference schedules

The sheet all_conferences in the main gsheet is used to populate the schedule in each conference event page.

Deploying the site

Note	Humans should not deploy the site, or work directly on master. The site is built automatically by the CICD process in .github/workflows/deploy.yml.

When deployments are triggered

Deployments to push up a new version of the site are triggered any time master branch is updated AND at 3am on Sunday via this line. The 3am Sunday builds are so minor updates to the gsheet appear in the site (as gsheet edits don’t trigger a build).

As a contributor

• To update the organising team, proceedings content or a schedule - edit the gsheet.

• To edit the website code - make your edits in a branch and make a PR onto master. Remember that the CICD process will rebuild (e.g. don’t worry about pushing up a built version of the site, or pulling updates from the gsheet.)

Details on how deploy.yml works

1. The master branch will be protected - so you can only do a PR in

2. When master is updated, it triggers .github/workflows/deploy.yml to run.

3. This will run the scripts in /build_scripts/ to update content where the source of truth is in the gsheet. Doing this overwrites folders like `/content/authors/ and /content/publications/.

4. deploy.yml references a secret in env:. This is the password needed to decrypt the service account token stored in inst (using inst as default location as it’s where people expect it when doing an R package). See /build_scripts/setup.R for how it was made. At the start of each script there is a verbose dance of code based on the R function gargle:::secret_read but modified to work outside the context of an R package (maybe should be a helper function rather than repeated in each script).

5. Then the deploy.yml script runs a second set of code that will run Hugo and then publish the output to a detached gh-pages branch.