自動更新Sublime Text 3的channel_v3.json
遇到的問題
由於最近一直在使用Sublime Text 3,所以不得不與它的包管理器Package Control打交道。之前使用官方的安裝方式,一直相處都很和諧,除了每次安裝包的時候,反應慢一些。但是今天不知爲何,卻怎麼也無法獲得完整的包目錄信息了。使用 `Ctrl-`` 查看控制檯,可以看到如下輸出:
Package Control: Attempting to use Urllib downloader due to WinINet error: Error downloading channel. Operation timed out (errno 12002) during HTTP write phase of downloading https://packagecontrol.io/channel_v3.json.
並會彈出這樣的窗口:
網上搜了一些帖子,瞭解到主要的原因還是因爲網絡問題無法獲取這裏需要的包信息文件 https://packagecontrol.io/channel_v3.json
。
解決方案
最有效的手段還是將其安置在一個更加容易獲取的地址裏。可以選擇的方式有很多:
- 本地。可以下載下來後,配置Package Control的用戶配置文件中的
channels
項,將其值設爲本地的路徑即可。 - 使用別人提供的已經保存好的文件地址,這裏修改使用即可。
但是這些方法得到的信息可能不是最新的,所以我們得想辦法讓這個使用的自定義地址鏈接的文件可以自動更新。所以這裏考慮使用Github提供的Github Actions功能來實現 克隆倉庫->下載文件->暫存修改->提交倉庫
的流程的自動處理。於是有了第三種策略:
- 使用Github Actions自動更新自己倉庫裏的json文件。
我的方案
首先明確,我們的過程:克隆倉庫->下載文件->暫存修改->提交倉庫
其次要簡單瞭解Github Actions的最簡單的使用方式。這裏我們參考文檔,官方也提供了中文的,雖然不是最新,但是卻也夠用了:https://help.github.com/cn/actions/configuring-and-managing-workflows/configuring-a-workflow(中文文檔的錨點不太好用,所以後文提供各項特定功能的鏈接的時候,使用的是英文文檔)。
這裏可以瞭解到Github Actions主要基於工作流程(workflows)的概念:
工作流程是您可以在倉庫中創建的自定義自動化流程,用於在 GitHub 上構建、測試、封裝、發行或部署任何項目。 通過工作流程可以利用廣泛的各種工具和服務自動化軟件開發生命週期。
創建工作流程
接下來我們開始創建屬於我們自己的工作流程。
您可以在倉庫中創建多個工作流程。 必須將工作流程存儲在倉庫根目錄的 .github/workflows 目錄中。
在倉庫根目錄的 .github/workflows
目錄中創建流程的YAML配置文件(https://www.codeproject.com/Articles/1214409/Learn-YAML-in-five-minutes),文件名字只要合法即可。這裏我們創建文件 update_robot.yml
作爲我們的配置文件。
具體的內容,參考我所使用的代碼註釋來解釋(註釋來自文檔):
# https://github.com/graueneko/aktools/blob/master/.github/workflows/autoupdate.yml
# https://github.com/Seniru/LineGraph-TFM/blob/master/.github/workflows/build.yml
# The name of your workflow. GitHub displays the names of your workflows
# on your repository's actions page. If you omit name, GitHub sets it to
# the workflow file path relative to the root of the repository.
name: Auto update data
# 這裏的空格在readme.md中的badge裏需要使用`%20`替換
# Required
# The name of the GitHub event that triggers the workflow.
# You can provide a single event string, array of events, array of event types,
# or an event configuration map that schedules a workflow or restricts the
# execution of a workflow to specific files, tags, or branch changes.
# For a list of available events, see "Events that trigger workflows."
on:
push:
branches:
- master
schedule:
- cron: '0 12 * * 1'
# A workflow run is made up of one or more jobs.
# Jobs run in parallel by default. To run jobs sequentially,
# you can define dependencies on other jobs using the jobs.<job_id>.needs keyword.
jobs:
# Each job must have an id to associate with the job.
# The key job_id is a string and its value is a map of the job's configuration data.
# You must replace <job_id> with a string that is unique to the jobs object.
# The <job_id> must start with a letter or _ and contain only alphanumeric characters, -, or _.
auto-update: # job_id
name: Update Files # 作業顯示在 GitHub 上的名稱。
# Required The type of machine to run the job on.
# The machine can be either a GitHub-hosted runner, or a self-hosted runner.
runs-on: ubuntu-latest
# A job contains a sequence of tasks called steps. Steps can run commands,
# run setup tasks, or run an action in your repository, a public repository,
# or an action published in a Docker registry. Not all steps run actions,
# but all actions run as a step. Each step runs in its own process in the runner
# environment and has access to the workspace and filesystem.
# Because steps run in their own process, changes to environment variables are not
# preserved between steps. GitHub provides built-in steps to set up and complete a job.
# You can run an unlimited number of steps as long as you are within the workflow usage limits.
steps:
- name: Check out repository
uses: actions/checkout@v2
- name: Download files
run: |
curl -sO https://packagecontrol.io/channel_v3.json
- name: Commit files
run: |
git config --local user.email "[email protected]"
git config --local user.name "GitHub Action"
git commit -m "Add changes" -a
- name: Push changes
uses: ad-m/github-push-action@master
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
# `secrets.GITHUB_TOKEN` 是由GITHUB自動生成的
從中我們可以瞭解到,一個合法的配置文件主要包含三個基本的key: name
on
jobs
。
關於配置文件中各個key的含義可以參考:
這裏重點介紹 on
和 jobs.<jobs_id>.steps
下的內容。
on
的設置表示何時執行該workflows,可以多種設定,具體可見https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#on。但是本文使用的是定時執行或者push觸發的設定:- 定時執行,也就是
schedule
,這裏需要配置cron
,這個配置語法可見https://www.yuque.com/lart/linux/crontab中的介紹。 push
觸發可以指定分支。
- 定時執行,也就是
- A job (指一個jobs_id下的內容) contains a sequence of tasks called
steps
,這裏存放着任務序列,會依次執行。 jobs.<job_id>.steps.name
Aname
for your step to display on GitHub. 這裏可以使用name來指定每個具體的步驟,後面可以接着特定的action或者指令來實現單獨的步驟。- 可以通過使用
run
來運行命令行的指令 https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsrun- 這裏我們通過
curl
來下載文件到當前的目錄下。 - 可以使用
run |
實現多個命令的使用。
- 這裏我們通過
- 可以通過使用
uses
來使用特定的action https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsuses- 一般而言,會涉及到一些action的使用的配置,這時可以參考對應的action倉庫的文檔,一般都有介紹。
- 這裏使用了
actions/checkout
來獲取源碼,使用的版本是v2。 - 這裏使用了
ad-m/github-push-action
來實現修改後的倉庫的提交。
- 可以通過使用
- 另外,關於這裏使用的
secrets.GITHUB_TOKEN
,這裏對應的實際上是當前倉庫的settings裏的secrets的environment variables,可以用來設定一些加密的信息。但是這裏使用的secrets.GITHUB_TOKEN
並不需要自行創建,這個是GitHub自動生成的。
當配置完成後,我們可以通過倉庫的Actions查看運行狀態。
同時我們在倉庫的readme.md添加一個指示工作流狀態的badge:https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#adding-a-workflow-status-badge-to-your-repository
這裏有好幾種方式添加,我是用的是https://help.github.com/en/actions/configuring-and-managing-workflows/configuring-a-workflow#example-using-a-workflow-name這種。
到此就OK了。
我們可以將對應的文件網址添加到Package Control的用戶配置中:
"channels":
[
"https://github.com/lartpang/AutoUpdateConfiguration/raw/master/channel_v3.json"
],
這個時候就可以正常使用了。