This is my github profile:
Popular Repos
Popular Blogs
| article | public_reactions_count | comments_count | page_views_count |
|---|---|---|---|
| I made my dev.to content into a website to find a new job | 36 | 3 | 518 |
| Why use AWS Lambda for Data Science? | 33 | 3 | 560 |
| Posting straight from .Rmd to dev.to (for real this time) | 18 | 0 | 173 |
| Local gitlab runners, ‘no such image’, docker and disk space | 9 | 0 | 600 |
| Writing R packages, fast | 8 | 0 | 14 |
Background
I made it because I saw this repo by zhiiyang
My name is Zhi (pronounced as Z). Welcome to my GitHub page! Here are highlights of my recent projects.
-
📱 A Phone Shiny app OTworkout to track your workout from GitHub. -
🤖 A Twitter bot mutsignatures using Python and AWS Lambda. -
📊 #TidyTuesday Data Visualization Gallery. -
📦 Two Bioconductor packages: HiLDA and selectKSigs. -
👇 You're viewing my lastest tweet deployed on GitHub actions.
Thanks to @mokkapps
for this article which uses the twitter updating
action for discovering it.
Motivation
It took my a little while to decide what to do with my profile. I wanted
something data driven, and I wanted something to show-off my programming
successes. So I decided to show my most popular repos, and also to show
my most popular dev.to posts! I noticed that zhiiiyang made extensive
use of r-lib/actions, and I’ve
found that it was really valuable for my project too!
Method
Repos
The repos script was where I started. Building from zhiiiyang’s work, I
built a GitHub
workflow
to call a script I had written.
The script was quite
simple.
It gets my repos from the GitHub API through the
gh package, and tidies the return using
hoist to grab the important bits. It then filters and pivots the data
into a simple plot.
The most interesting part was where zhiiiyang added the output as a
commit by the action itself. The authentication for the action is
actually allowed by this section:
env:
GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
I did stumble a little over the correct path to the plot image. It turns
out that you can use the relative location (./graph.png) which will
work if you are viewing the README from within the repo, but to make
it work when the README is displayed from my user page you have to use
the absolute path
(https://github.com/daveparr/daveparr/blob/main/graph.png).
Posts
The posts was actually pretty easy once I’d got used to how GitHub
Action operate, and also how the GitHub README profiles worked.
The key part was actually a feature I recently developed for my own
package.
.to.ol
The goal of dev.to.ol is to help R users publish to dev.to
Installation
You can install the dev.to.ol from github with
remotes:
remotes::install.github("DaveParr/dev.to.ol")
Workflow
Create your article
The create_new_article function will give you the front mattter
boilerplate for an article .Rmd file. Optionally supplying a file name
will create a new file with the front matter at the start.
create_new_article(title = "my title")
Write your article!
This is the fun bit. Mark your great ideas down in an .Rmd!
Post your article
Once the .Rmd is written, you can post it to dev.to with
post_new_article
post_new_article("./my-great-article.Rmd")
Check your articles
There are two functions to check the posted articles on dev.to, published and unpublished. Both will return a ‘tidy’ data set by default.
get_users_articles()
Using DEVTO in .Renviron
The API returned the expected success…dev.to.ol is a package to help R users manage their dev.to content. In
particular I had recently finished the functions that return data from
the API about your published articles. The key to this is to have the
DEV.TO api key that you want to use set as an encrypted secret in the
repo. once that is set, my package can read it if it’s set as an
environmental variable along with the GITHUB_PAT.
env:
DEVTO: ${{ secrets.DEVTO }}
GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
Because my package returns a tidy data.frame like object, it was trivial
to munge it down to just what I wanted to show, and then format it
neatly with knitr. I also went all in on the r-lib/actions examples,
and now not only generate the new data for both the chart and blogs
during the GitHub action, but also do the full compile from .Rmd to
.md using the setup-pandoc
action.
Lessons in automation
I’d been meaning to explore GitHub Actions for a little while, and I
found a few things out that I’m going to be considering in the future as
I develop this an other projects.
Pricing vs performance on macOS and Linux
It’s free to a point, and then you need to pay. I had a look at the
pricing
plan
and noticed that your runtime impacts your pricing. Most of the examples
from r-lib/actions run from macos-latest, as does zhiiiyang’s project.
In GitHub Actions pricing a minute of macOS runtime is worth 10
minutes of linux runtime. I ran on macOS for a while too, but
eventually thought that it might be a smart idea for a long running
personal project to convert to a linux run time, though now I’ve done it
I’m debating going back to mac.
The ‘problem’ is that I did not write this process to be fast, or light.
It’s a silly hobby project to over-automate because I can. Therefore, on
Linux I am now actually compiling the packages on each installation
AND installing libcurl for the api
calls.
The cost savings I make from not picking the faster run time in this
case are approximately negated by the increase in actual run time. By
eye, that part of the job runs at about 10 minutes now, where as on mac
it was about 10 times faster as the pre-compiled binaries could just be
downloaded and would run ‘out of the box’. I’ll probably change it back
in a little while after I’ve checked how variable it can be.
Potential solutions could include some form of caching (which I’ve heard
is maybe supported?) or running the action in my own docker image with
the pre-compiled, though TBH that sounds like work, and this is supposed
to be fun :P
r-lib actions for the Rmd
I really like the idea of compiling the README.md for a package from
the README.Rmd we often use in R. I’ve often forgotten in my own work
to do that key step before a push, and having a relatively simple
automation backed into where my repos live will likely be something I
use in the future. The best part of this trick is that r-libs/actions
does the most irritating part of ‘making Pandoc work’ for me. So I can
just profit!
Successs!
I really liked hacking this out. I got to put my dev.to.ol package to
another practical lesson and learn about GitHub Actions. Feel free to
re-create this on your profiles, either by grabbing bits or by just
lifting the whole thing. One of the reasons I built it the way I did is
so it could be relatively portable between users, and maybe solve a
problem for more than just me. So if you get this deployed on your
profile, or get stuck, I’d love to hear from you!
Top comments (0)