The docs had two tutorials: one using JavaScript and one using Docker. I was pleasantly surprised at the extent of Github's documentation on the subject, and it would become the first of a few sacred texts I relied on throughout my project.
#THE SYNDICATE PROJECT SETUP HOW TO#
Github is my private choice of remote source control platform, so I looked into Actions and how to create them. And it would be awesome to have some sort of interface for monitoring progress and output, and maybe even a logging mechanism. on a push command) and run on someone else's computer, rather than operating on a user's local machine it would minimize "works on my machine ¯\_(ツ)_/¯" headaches when installing and using the tool itself. Thinking about Github Actions made me realize it would be nice to have my tool respond to changes on a remote repository (i.e. I hadn't really imagined that the tool I would build might have any actual interface besides an automatic trigger. I didn't really know what they were, but on the surface it seemed like a Github service implemented on top of git hooks. Recently, though, I noticed something called Actions show up on my Github repositories. They seemed like the perfect mechanism to use for this project. I've played with git hooks in the past for doing things like automatically injecting a JIRA ticket number into my commit messages when pushing and automatically running database migrations locally after pulling if the schema changed or migration files were added. My next question was one of automation: how to trigger a DEV.to API call in response to changes in my git repository? My immediate reaction was " git hooks." Thankfully, my project was saved by a quick Google search: DEV has a beta API that exposes end points I could leverage. One of my first questions was, "Can I communicate with DEV.to programmatically?" DEV.to is currently the only place I publish writing, so if the only answer involved pretending to be a human and programmatically engaging with the UI to manipulate blog posts, I was likely to abandon the idea (though I probably would have tried it just for fun).
In essence, the thing I wanted to build would take changes I made to files in a git repo, and push them someplace else. It took me a week of focused evenings and a weekend of dedicated hacking to polish it to my liking and another week to write about it. It distributes copies of the content you create to various publishing sites automatically. A simple implementation of the POSSE content publishing model
0 kommentar(er)
