Post dev.to articles from gitlab

Whether you review your draft dev.to articles alone or with friends, markdown and gitlab make it very easy to talk about changes, so here is a way to write dev.to articles on gitlab and schedule their publishing.

Jason Yavorska

@j4yav

Wikis seriously need a merge request like workflow.

15:20 PM - 12 Nov 2020

Amir Salihefendić

@amix3k

@astralwave Tools like Notion or Confluence are horrible at storing more permanent knowledge, e.g., it's hard to structure things, things aren't peer-reviewed, logs are an afterthought.

Git solves this in elegant ways. It's harder to use, but we didn't optimize for ease of usage.

10:34 AM - 13 Nov 2020

Instructions

1. fork this gitlab repository
2. at dev.to generate token
3. at gitlab set masked CI env vars DEV_TO_API_KEY, DEV_TO_NAME
4. at gitlab set personal access token with write repository permissions
5. at gitlab set CI env vars masked GITLAB_TOKEN
6. at gitlab set a scheduled pipeline on a daily basis

How it works

Gitlab CI processes entries in state.yml of master branch daily like the following:

- filename: update.md
  date: 2020-11-08
  slug: generated-post-19p6

If today is 2020-11-08 then it updates the article with title mentioned in update.md.

And if the article does not exist, it creates it and updates state.yml with its slug so that it can update it in the future if instructed by state.yml.

Internally, the whole logic of the ruby script is about putting the markdown on the body_markdown param of the dev.to API.

If GET articles/#{username}/#{slug} returns HTTP 200, then PUT articles/#{id} otherwise POST articles.

The editing pipeline as a...pipeline

Each time you want to write a new article, open a Merge Request, create an entry at state.yml and a file.

Then the most important step is to discuss it with others and review it in an MR like this

Making the editing pipeline explicit in gitlab also opens the road to storing metrics (like number of comments) on state.yml and to further automation like daily checking for broken links, correcting spelling and grammar mistakes, cross-posting, etc.

When ready, merge the MR. The next day in the scheduled timing it will appear at dev.to.

Format

Custom variables can be set for each post, located between the triple-dashed lines in your editor. Make sure published is true and that there is a unique title:

• title: the title of your article
• published: boolean that determines whether or not your article is published
• description: description area in Twitter cards and open graph cards
• tags: max of four tags, needs to be comma-separated
• canonical_url: link for the canonical version of the content
• cover_image: cover image for post, accepts a URL. The best size is 1000 x 420.
• series: post series name.

Next step

To edit this post, the ruby script or its tests, feel free to open an issue.