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.

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.

Comments

[Gary Bell]

This is fantastic.

I need to find (ok, or write) one to post to my Ghost blog, then use this to cross-post a few days later.

I probably won't, but it would be awesome.

Absolute love for using GitLab

[nickmaris]

Hi @_garybell !

The bad news is that Ghost staff suggests going from markdown to HTML to one large HTML mobiledoc card and when I tried it, hyperlinks were not clickable. Same for one large markdown mobiledoc card.

The good news is that DEV can publish from RSS but note that posts will land in your dashboard as drafts.

Hope it helps.

PS: Finally I found the right reply button to avoid endless indentation :)

[Gary Bell]

The ghost part was a pipe dream. I need to look at whether that is my long term platform of choice.

I'm writing a load of posts about GitLab for next year so cross-posting here with minimal effort will be great

[nickmaris]

You can host your blog on gitlab pages and use the variable canonical_url (like username.gitlab.io/post1) in the markdown header to be utilized when posting to DEV.

For example, this minimal setup or Vuepress hosted in gitlab pages with comments stored as gitlab issues and a newsletter, all out of the box, info from git, table of contents and a medium like theme

[Gary Bell]

That's one of my things to investigate next year. And also to blog about.

I really need to make sure I have a list of things to investigate and learn

[nickmaris]

Cool! I am preparing a post for an ansible based public repository for GitLab Athens meetup and anyone else interested in installing and configuring a demo gitlab instance to explore configuration options.

[Gary Bell]

I'd absolutely love to see that. I've been doing a bit of Ansible lately.

I am weighing up whether to run an instance at work, or run GitLab SaaS with runners in the cloud. Would be interesting to see the Ansible config to get an idea of possibilities

[nickmaris]

I am curious to see cross-posting working. If I write it (as a really alpha-version ruby gem), would you use it? :)

ghost.org/docs/api/v3/admin/#posts

[Gary Bell]

I'd give it a go.

I'm currently writing a series of posts about GitLab features for next year. They are all in GitLab at present, so it's just setting up the CI. Will save me copy and paste time.