最近几年来，老T在静态博客发布这件事情上也算是走了无数弯路。随便搜下老T博客，关于Hugo的数篇文章，无一不是聚焦这个问题。但细数以前的经历，不管是哪种方法，很少有能让老T坚持一个星期以上还主动愿意持续用下去的。大多数时候用它们都是处于一种迫不得已的”窘境“。如今，终极解决方案来了。
使用 Github issue 作为静态博客的发布端
国内网络环境下，Github Mobile 是一个远比 GIthub 网站更稳定的应用。老T最开始萌生用 Github issue 当成博客发布端，是在今年初看到 Hackernews 上一则帖子，提到 Github issue 由于几乎无数量、容量限制，可能是最佳的博客写作平台。可由于长期以来 Github 在国内网络环境下一直处于抽风状态，所以老T并没有去试验这种方法。
直到今年 7 月份，老T在为博客添加一个”说说“功能时，才再度想起 Github issue 的便利性，当时也写了个简单教程：只需 2 步简单操作，一劳永逸解决静态博客添加朋友圈、说说之类的功能
不过那一次主要解决的是博客端添加”说说“功能，而发布过程的便捷性方面并没探索，直到最近用上 Github APP + Shortcut Marker ，在手机上只需点2次就能开始添加图片发”说说“，这过程，比微信发朋友圈的4次点击还要简单（打开微信—发现—朋友圈—发布）。
在持续高强度用了几天后，我开始真心喜欢上这种更新博客方式，仿佛又回到从前用 WordPress 的时代。也就是在这过程中，我开始思考，能不能把日常一些短平快的文章，也通过这种方式发布呢？
老T在周五晚上睡觉前，简单构思了一下这个事情。觉得不外乎就是三个问题：1.提取 issue 内容并转换为 markdown文件；2.转存图片；3.触发逻辑设置。于是周末开干，找了个缩小版的老T博客仓库进行测试。最终，只需要添加两个工作流文件即可实现这一目标。
