<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Taskfile on Tux-Sudo</title><link>https://blog.tux-sudo.com/tags/taskfile/</link><description>Recent content in Taskfile on Tux-Sudo</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 23 Dec 2019 05:32:57 +0000</lastBuildDate><atom:link href="https://blog.tux-sudo.com/tags/taskfile/index.xml" rel="self" type="application/rss+xml"/><item><title>Go: Useful Development Workflows</title><link>https://blog.tux-sudo.com/posts/golang-github-actions/</link><pubDate>Mon, 23 Dec 2019 05:32:57 +0000</pubDate><guid>https://blog.tux-sudo.com/posts/golang-github-actions/</guid><description>&lt;p&gt;Code Coverage, Static Code Analysis, Tests, Releases? What else? Probably a few more things, but you get the point. These are all things that are expected to be part of a modern day development workflow. While this is becoming the norm in companies, a lot of pet open-source projects still skimp on these things. And frankly, I did too. I wasn&amp;rsquo;t going to bother hosting my own Jenkins behemoth just so my soon-to-be abandoned project could run a few builds. But with practically everything available as a SaaS (and in most cases, free for open source projects), I had no excuse anymore.
Travis/Circle/GitlabCI/AzurePipelines etc. were already quite common and with GitHub&amp;rsquo;s entry into the fray, there really is no reason not to have atleast a simple CI workflow on your project.&lt;/p&gt;</description></item></channel></rss>