-
Notifications
You must be signed in to change notification settings - Fork 9
New tutorial on using R keyring
#365
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
base: master
Are you sure you want to change the base?
Conversation
|
this is ready to be reviewed, thank you! |
RCinbo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've read your tutorial with great interest and have made some small textual suggestions.
I have only used keyring once in one repository.
What I often do, is store passwords as environmental variables in an .Renviron file (include this file in gitignore so it is not shared) and then get them when I need them with Sys.getenv(). It's simpler then what I read here but probably not as safe since anyone with access to my computer can read it...
Co-authored-by: raisa_carmen <[email protected]>
Co-authored-by: raisa_carmen <[email protected]>
Co-authored-by: raisa_carmen <[email protected]>
|
Thank you @RCinbo for reviewing and finding the typo's. I have re-read it as well; ready for publication from my side. |
Description
Sharing some best practices which I experienced when using
keyringin a set of automated scripts.Related Issue
None.
Task list
tutorials/content/index.md. In case of an Rmarkdown tutorial I have knitted myindex.Rmdtoindex.md(both files are pushed to the repo).yamlheader:authorsyaml tag, using[MY_AUTHOR_ID]. An author information file exists in<tutorials>/data/authors/<author>.toml.categoriesto the YAML header and my category tags are from the list of categories.tags(i.e. keywords) in the YAML header to improve the visibility of the new tutorial (see the tags listed in the tutorials website side bar).dateis in formatYYYY-MM-DDand adjusted.Previewing the pull request
Thanks to GitHub Actions, an artifact (=zip file) of the rendered website is automatically created for each pull request.
This provides a way to preview how these updates will look on the website, useful to contributors and reviewers.
Instructions to preview the updated website
Downloads/tutorials_preview.httpsites on your local machine. One such option is theservrpackage in R:& '\C:\Program Files\R\R-4.4.2\bin\Rscript.exe' -e "servr::httd('./tutorials_preview')" -p8887(make sure to adjust the path to yourRscript.exe; on Linux, simply useRscript -e [...]).Note: for step 3, you can use any other simple HTTP server to serve the current directory, e.g. Python
http.server:python -m http.server 8887 --bind localhost --directory path/to/tutorials_previewAlternative: Locally Building the Site
Alternatively, you can build the entire site locally (see the README for instructions); the Hugo preview server will update changes on the fly.
This requires Hugo to be installed on your computer.