Amo Wu's Blog

如何自動化 GitHub Releases 流程 2017 年初的時候，曾經寫了《 如何自動化 release 的流程？ 》這篇文章，介紹了如何利用 semantic-release 和 TravisCI 自動化 GitHub Releases 和 NPM publish 這件事。這次要介紹的是如何直接透過 Probot 機器人做到 GitHub Releases。 大綱 什麼是 GitHub Releases？ GitHub Releases 有什麼問題？ 什麼是 Conventional Commits？ 什麼是 Conventional Release Bot？ 為什麼要用 Conventional Release Bot？ 什麼是 GitHub Releases？ GitHub Releases 是 GitHub 提供給每個專案在釋出（Release）新版軟體時，用來紀錄更新內容（Change Log）的頁面。 GitHub Releases 通過 GitHub Releases，你可以為每次的 release 加入說明，描述該 release 進行了哪些更改。 GitHub Releases 的基礎是建立在 Git tags 之上。Tags 代表了你的專案在某個特定時間點下的里程碑，所以它會是一個很好的 release 表達方式。 更多有關於 Git tags 的資訊可以參考 GitHub 的《 Working With Tags 》。 GitHub Releases 有什麼問題？ 我們團隊在執行 release 的過程中碰到過不少問題，總結如下： 無法回憶起曾經「新增了哪些功能」或「修復了哪些問題」，就像突然有人問「你記得上禮拜二中午吃什麼嗎？」的感覺，每次負責 release 的人都要口頭一個一個問其他工程師，最後崩潰躲在角落獨自一個人慢慢爬 commit log⋯⋯😢 Push 或 merged master 的當下就應該馬上 release Git tag，但是常常會忘記做這件事，導致之後想起來還要回去找 commit SHA 才能補上 tag 不是所有人都知道 SemVer 的版本號更新規則 Git tag 下在錯誤的 branch：因為有些 rep...

最近 Bower 宣布停止維護，所以許多前端的 packages 都移到了 NPM 上，甚至連 Grunt 和 Gulp 這類 build tools 都有要被 NPM scripts 取代的趨勢。 這篇文章主要是紀錄怎麼在發布自己的 package 之前，打包好需要的檔案。 假設你會使用 Grunt 或 Gulp 將所有原始碼打包存成一支檔案，例如 dist/build.js ，但是因為通常我們不會把 dist 這類輸出文件放進版本控制，所以要在每次發布新版本的時候動態打包。 方法是在 package.json 的 script 底下新增一個 prepublish 的腳本，然後把你的打包命令寫在這裡： // package.json { "script": { "prepublish": "..." // grunt or gulp } } 接下來是透過 main 指定程式的進入位置，讓其他人在使用的時候可以正常的 require 或 import 你的 package。 預設的檔案通常是 index.js ，這裡我們把它改成剛剛打包完成的 dist/buid.js ： // package.json { "main": "dist/build.js" } 最後也是最重要的部分，記得在專案根目錄新增一份 .npmignore 的空檔案，因為如果沒有它，NPM 在發布的時候會參考 .gitignore 的清單來決定哪些檔案不能被發布，而通常 dist 就會在這裡面，所以要將它從 .npmignore 裡面移除。 都準備完成之後就可以發布了，如果你還沒有 NPM 的帳號，可以註冊一個： npm adduser 然後發布新版本： npm publish 記得更新 package.json 的 version 才能發布 發布成功之後前往 http://npmjs.com/package/name 看結果： 完整專案可以參考我的 GitHub 參考文章 Publishing npm packages