github pages

Teams who work on GitHub rely on event data to collaborate. ?The data recorded as issues, pull requests, and comments become vital to understanding the project.

在GitHub上工作的團(tuán)隊(duì)依靠事件數(shù)據(jù)進(jìn)行協(xié)作。 記錄為問題，請求和注釋的數(shù)據(jù)對于理解項(xiàng)目至關(guān)重要。

With the general availability of GitHub Actions, we have a chance to programmatically access and preserve GitHub event data in our repository. Making the data part of the repository itself is a way of preserving it outside of GitHub. It also gives us the ability to feature the data on a front-facing website, such as with GitHub Pages.

有了GitHub Actions的普遍可用性，我們就有機(jī)會以編程方式訪問并在我們的存儲庫中保存GitHub事件數(shù)據(jù)。 使數(shù)據(jù)成為存儲庫本身的一部分是將其保存在GitHub之外的一種方法。 它還使我們能夠在前端網(wǎng)站(例如GitHub Pages)上顯示數(shù)據(jù)。

And, if you’re like me, you can turn GitHub issue comments into an awesome 90s guestbook page.

而且，如果您像我一樣，可以將GitHub問題評論變成一個(gè)很棒的90年代留言簿頁面 。

No matter the usage, the principle concepts are the same. We can use Actions to access, preserve, and display GitHub event data - with just one workflow file. To illustrate the process, I’ll take you through the workflow code that makes my guestbook shine on.

無論用法如何，其原理都是相同的。 我們可以使用Actions來訪問，保留和顯示GitHub事件數(shù)據(jù)-只需一個(gè)工作流文件。 為了說明該過程，我將帶您瀏覽使我的留言簿更加生動的工作流代碼 。

For an introductory look at GitHub Actions including how workflows are triggered, see A lightweight, tool-agnostic CI/CD flow with GitHub Actions.

有關(guān)GitHub Actions(包括如何觸發(fā)工作流)的入門介紹，請參閱GitHub Actions中的工具無關(guān)的輕量級CI / CD流 。

訪問GitHub事件數(shù)據(jù) (Accessing GitHub event data)

An Action workflow runs in an environment with some default environment variables. A lot of convenient information is available here, including event data. The most complete way to access the event data is using the $GITHUB_EVENT_PATH variable, the path of the file with the complete JSON event payload.

Action工作流在具有某些默認(rèn)環(huán)境變量的環(huán)境中運(yùn)行。 此處提供了許多方便的信息，包括事件數(shù)據(jù)。 訪問事件數(shù)據(jù)的最完整方法是使用$GITHUB_EVENT_PATH變量，即帶有完整JSON事件有效負(fù)載的文件路徑。

The expanded path looks like /home/runner/work/_temp/_github_workflow/event.json and its data corresponds to its webhook event. You can find the documentation for webhook event data in GitHub REST API Event Types and Payloads. To make the JSON data available in the workflow environment, you can use a tool like jq to parse the event data and put it in an environment variable.

擴(kuò)展路徑類似于/home/runner/work/_temp/_github_workflow/event.json ，其數(shù)據(jù)對應(yīng)于其webhook事件。 您可以在GitHub REST API 事件類型和有效負(fù)載中找到webhook事件數(shù)據(jù)的文檔。 要使JSON數(shù)據(jù)在工作流環(huán)境中可用，您可以使用jq類的工具來解析事件數(shù)據(jù)并將其放入環(huán)境變量中。

Below, I grab the comment ID from an issue comment event:

下面，我從問題評論事件中獲取評論ID：

ID="$(jq '.comment.id' $GITHUB_EVENT_PATH)"

Most event data is also available via the github.event context variable without needing to parse JSON. The fields are accessed using dot notation, as in the example below where I grab the same comment ID:

大多數(shù)事件數(shù)據(jù)也可以通過github.event上下文變量獲得，而無需解析JSON。 可以使用點(diǎn)表示法來訪問這些字段，如下面的示例所示，其中我獲取了相同的注釋ID：

ID=${{ github.event.comment.id }}

For my guestbook, I want to display entries with the user’s handle, and the date and time. I can capture this event data like so:

對于我的留言簿，我想顯示帶有用戶句柄以及日期和時(shí)間的條目。 我可以像這樣捕獲此事件數(shù)據(jù)：

AUTHOR=${{ github.event.comment.user.login }} DATE=${{ github.event.comment.created_at }}

Shell variables are handy for accessing data, however, they’re ephemeral. The workflow environment is created anew each run, and even shell variables set in one step do not persist to other steps. To persist the captured data, you have two options: use artifacts, or commit it to the repository.

Shell變量很容易訪問數(shù)據(jù)，但是它們是短暫的。 每次運(yùn)行都會重新創(chuàng)建工作流環(huán)境，甚至在一個(gè)步驟中設(shè)置的Shell變量也不會保留到其他步驟。 要持久保存捕獲的數(shù)據(jù)，您有兩個(gè)選擇：使用構(gòu)件，或?qū)⑵涮峤坏酱鎯臁?

保留事件數(shù)據(jù)：使用工件 (Preserving event data: using artifacts)

Using artifacts, you can persist data between workflow jobs without committing it to your repository. This is handy when, for example, you wish to transform or incorporate the data before putting it somewhere more permanent. It’s necessary to persist data between workflow jobs because:

使用工件，您可以在工作流作業(yè)之間保留數(shù)據(jù)，而無需將其提交到存儲庫。 例如，當(dāng)您希望在將數(shù)據(jù)放置到更永久的位置之前進(jìn)行轉(zhuǎn)換或合并時(shí)，這非常方便。 有必要在工作流作業(yè)之間保留數(shù)據(jù)，因?yàn)?#xff1a;

Each job in a workflow runs in a fresh instance of the virtual environment. When the job completes, the runner terminates and deletes the instance of the virtual environment. (Persisting workflow data using artifacts)

工作流中的每個(gè)作業(yè)都在虛擬環(huán)境的新實(shí)例中運(yùn)行。 作業(yè)完成后，運(yùn)行程序終止并刪除虛擬環(huán)境的實(shí)例。 ( 使用工件保留工作流數(shù)據(jù) )

Two actions assist with using artifacts: upload-artifact and download-artifact. You can use these actions to make files available to other jobs in the same workflow. For a full example, see passing data between jobs in a workflow.

有兩種操作可幫助使用工件： upload-artifact和download-artifact 。 您可以使用這些操作使文件可用于同一工作流程中的其他作業(yè)。 有關(guān)完整示例，請參見工作流中作業(yè)之間的數(shù)據(jù)傳遞 。

The upload-artifact action’s action.yml contains an explanation of the keywords. The uploaded files are saved in .zip format. Another job in the same workflow run can use the download-artifact action to utilize the data in another step.

upload-artifact操作的action.yml包含關(guān)鍵字的說明 。 上載的文件以.zip格式保存。 同一工作流運(yùn)行中的另一個(gè)作業(yè)可以在另一個(gè)步驟中使用download-artifact操作來利用數(shù)據(jù)。

You can also manually download the archive on the workflow run page, under the repository’s Actions tab.

您也可以在工作流運(yùn)行頁面上，在存儲庫的“操作”選項(xiàng)卡下手動下載存檔。

Persisting workflow data between jobs does not make any changes to the repository files, as the artifacts generated live only in the workflow environment.

在作業(yè)之間保留工作流數(shù)據(jù)不會對存儲庫文件進(jìn)行任何更改，因?yàn)樯傻墓ぜH在工作流環(huán)境中有效。

Personally, being comfortable working in a shell ?environment, I see a narrow use case for artifacts, though I’d have been remiss not to mention them. Besides passing data between jobs, they could be useful for creating .zip format archives of, say, test output data. In the case of my guestbook example, I simply ran all ?the necessary steps in one job, negating any need for passing data ?between jobs.

就個(gè)人而言，在外殼環(huán)境中工作自如，我看到了工件的狹窄用例，盡管我一直不愿提及它們。 除了在作業(yè)之間傳遞數(shù)據(jù)外，它們對于創(chuàng)建.zip格式的存檔(例如測試輸出數(shù)據(jù))很有用。 就我的留言簿示例而言，我只需在一個(gè)作業(yè)中運(yùn)行所有必要的步驟，而無需在作業(yè)之間傳遞數(shù)據(jù)。

保留事件數(shù)據(jù)：將工作流文件推送到存儲庫 (Preserving event data: pushing workflow files to the repository)

To preserve data captured in the workflow in the repository itself, it is necessary to add and push this data to the Git repository. You can do this in the workflow by creating new files with the data, or by appending data to existing files, using shell commands.

為了將工作流程中捕獲的數(shù)據(jù)保留在存儲庫本身中，有必要將這些數(shù)據(jù)添加并推送到Git存儲庫中。 您可以在工作流中通過使用數(shù)據(jù)創(chuàng)建新文件或使用Shell命令將數(shù)據(jù)附加到現(xiàn)有文件中來完成此操作。

在工作流程中創(chuàng)建文件 (Creating files in the workflow)

To work with the repository files in the workflow, use the checkout action to first get a copy to work with:

要在工作流中使用存儲庫文件，請使用checkout操作首先獲取要使用的副本：

- uses: actions/checkout@masterwith:fetch-depth: 1

To add comments to my guestbook, I turn the event data captured in shell variables into proper files, using substitutions in shell parameter expansion to sanitize user input and translate newlines to paragraphs. I wrote previously about why user input should be treated carefully.

要將注釋添加到我的留言簿中，我將在shell變量中捕獲的事件數(shù)據(jù)轉(zhuǎn)換為適當(dāng)?shù)奈募?#xff0c;使用shell參數(shù)擴(kuò)展中的替換項(xiàng)來清理用戶輸入并將換行符轉(zhuǎn)換為段落。 之前，我寫過關(guān)于為什么應(yīng)謹(jǐn)慎對待用戶輸入的文章 。

- name: Turn comment into filerun: |ID=${{ github.event.comment.id }}AUTHOR=${{ github.event.comment.user.login }}DATE=${{ github.event.comment.created_at }}COMMENT=$(echo "${{ github.event.comment.body }}")NO_TAGS=${COMMENT//[<>]/\`}FOLDER=commentsprintf '%b\n' "<div class=\"comment\"><p>${AUTHOR} says:</p><p>${NO_TAGS//$'\n'/\<\/p\>\<p\>}</p><p>${DATE}</p></div>\r\n" > ${FOLDER}/${ID}.html

By using printf and directing its output with > to a new file, the event data is transformed into an HTML file, named with the comment ID number, that contains the captured event data. Formatted, it looks like:

通過使用printf并將其輸出帶有>定向到新文件，事件數(shù)據(jù)將轉(zhuǎn)換為HTML文件，該文件以注釋ID號命名，其中包含捕獲的事件數(shù)據(jù)。 格式化后，它看起來像：

<div class="comment"><p>victoriadrake says:</p><p>This is a comment!</p><p>2019-11-04T00:28:36Z</p> </div>

When working with comments, one effect of naming files using the comment ID is that a new file with the same ID will overwrite the previous. This is handy for a guestbook, as it allows any edits to a comment to replace the original comment file.

使用注釋時(shí)，使用注釋ID命名文件的一個(gè)效果是，具有相同ID的新文件將覆蓋前一個(gè)文件。 這對于留言簿非常方便，因?yàn)樗试S對注釋的任何編輯來替換原始注釋文件。

If you’re using a static site generator like Hugo, you could build a Markdown format file, stick it in your content/ folder, and the regular site build will take care of the rest.

如果您使用的是Hugo之類的靜態(tài)網(wǎng)站生成器，則可以構(gòu)建Markdown格式的文件，并將其粘貼在content/文件夾中，其余的工作將由常規(guī)網(wǎng)站進(jìn)行。

In the case of my simplistic guestbook, I have an extra step to consolidate the ?individual comment files into a page. Each time it runs, it overwrites the existing index.html with the header.html portion (>), then finds and appends (>>) all the comment files’ contents in descending order, and lastly appends the footer.html portion to end the page.

對于我的簡單留言簿，我還有一個(gè)額外的步驟將單個(gè)注釋文件整合到頁面中。 每次運(yùn)行時(shí)，它都會用header.html部分( > )覆蓋現(xiàn)有的index.html ，然后以降序查找并附加( >> )所有注釋文件的內(nèi)容，最后將footer.html部分附加到末尾。這一頁。

- name: Assemble pagerun: |cat header.html > index.htmlfind comments/ -name "*.html" | sort -r | xargs -I % cat % >> index.htmlcat footer.html >> index.html

提交對存儲庫的更改 (Committing changes to the repository)

Since the checkout action is not quite the same as cloning the repository, at time of writing, there are some issues still to work around. A couple extra steps are necessary to pull, checkout, and successfully push changes back to the master branch, but this is pretty trivially done in the shell.

由于checkout操作與克隆存儲庫不太一樣，因此在撰寫本文時(shí)，仍有一些問題需要解決。 需要幾個(gè)額外的步驟才能pull ， checkout和成功地push更改push回master分支，但這在shell中非常簡單。

Below is the step that adds, commits, and pushes changes made by the workflow back to the repository’s master branch.

以下是添加，提交并將工作流所做的更改推回存儲庫的master分支的步驟。

- name: Push changes to reporun: |REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}git config user.email "${{ github.actor }}@users.noreply.github.com"git config user.name "${{ github.actor }}"git pull ${REMOTE}git checkout mastergit add .git statusgit commit -am "Add new comment"git push ${REMOTE} master

The remote, in fact, our repository, is specified using the github.repository context variable. For our workflow to be allowed to push to master, we use the secrets.GITHUB_TOKEN variable.

遠(yuǎn)程，實(shí)際上是我們的存儲庫，是使用github.repository上下文變量指定的。 為了使我們的工作流程能夠掌握，我們使用secrets.GITHUB_TOKEN變量。

Since the workflow environment is shiny and newborn, we need to configure Git. In the above example, I’ve used the github.actor context variable to input the username of the account initiating the workflow. The email is similarly configured using the default noreply GitHub email address.

由于工作流環(huán)境充滿生機(jī)和新生，我們需要配置Git。 在上面的示例中，我使用了github.actor上下文變量來輸入啟動工作流程的帳戶的用戶名。 使用默認(rèn)的noreply GitHub電子郵件地址類似地配置電子郵件 。

顯示事件數(shù)據(jù) (Displaying event data)

Nov 6, 2019 correction: GitHub Actions requires a Personal Access Token to trigger a Pages site build.

2019年11月6日更正：GitHub Actions需要一個(gè)Personal Access Token來觸發(fā)Pages網(wǎng)站構(gòu)建。

If you're using GitHub Pages with the default secrets.GITHUB_TOKEN variable and without a site generator, pushing changes to the ?repository in the workflow will only update the repository files. The ?GitHub Pages build will fail with an error, "Your site is having ?problems building: Page build failed."

如果您使用具有默認(rèn)secrets.GITHUB_TOKEN變量且沒有網(wǎng)站生成器的GitHub Pages，則將更改推送到工作流中的存儲庫只會更新存儲庫文件。 GitHub Pages構(gòu)建將失敗，并顯示錯(cuò)誤：“您的網(wǎng)站構(gòu)建存在問題：頁面構(gòu)建失敗。”

To enable Actions to trigger a Pages site build, you'll need to create a Personal Access Token. This token can be stored as a secret in the repository settings and passed into the workflow in place of the default secrets.GITHUB_TOKEN variable. I wrote more about Actions environment and variables in this post.

要使操作能夠觸發(fā)Pages網(wǎng)站構(gòu)建，您需要?jiǎng)?chuàng)建一個(gè)個(gè)人訪問令牌。 該令牌可以作為機(jī)密存儲在存儲庫設(shè)置中，并代替默認(rèn)的secrets.GITHUB_TOKEN變量傳遞到工作流中。 我在這篇文章中寫了更多有關(guān)Actions環(huán)境和變量的文章 。

With the use of a Personal Access Token, a push initiated by the ?Actions workflow will also update the Pages site. You can see it for ?yourself by leaving a comment in my guestbook! ?The comment creation event triggers the workflow, which then takes ?around 30 seconds to a minute to run and update the guestbook page.

通過使用個(gè)人訪問令牌，由“動作”工作流啟動的推送也將更新“頁面”站點(diǎn)。 您可以在留言簿中 留下評論 ，親自查看！ 注釋創(chuàng)建事件觸發(fā)工作流程，然后運(yùn)行大約30秒到一分鐘來運(yùn)行和更新留言簿頁面。

Where a site build is necessary for changes to be published, such as ?when using Hugo, an Action can do this too. However, in order to avoid ?creating unintended loops, one Action workflow will not trigger another. Instead, it's extremely convenient to handle the process of building the site with a Makefile, ?which any workflow can then run. Simply add running the Makefile as the ?final step in your workflow job, with the repository token where ?necessary:

在需要發(fā)布網(wǎng)站更改才能發(fā)布的地方(例如使用Hugo時(shí))，Action也可以這樣做。 但是，為了避免創(chuàng)建意外的循環(huán)， 一個(gè)Action工作流程將不會觸發(fā)另一個(gè) 。 取而代之的是， 使用Makefile處理構(gòu)建網(wǎng)站的過程非常方便，然后任何工作流都可以運(yùn)行該文件 。 只需添加運(yùn)行Makefile作為工作流程工作的最后一步，并在必要時(shí)添加存儲庫令牌：

- name: Run Makefileenv:TOKEN: ${{ secrets.GITHUB_TOKEN }}run: make all

This ensures that the final step of your workflow builds and deploys the updated site.

這樣可以確保工作流程的最后一步可以構(gòu)建和部署更新的站點(diǎn)。

不再有事件數(shù)據(jù)范圍 (No more event data horizon)

GitHub Actions provides a neat way to capture and utilize event data so that it’s not only available within GitHub. The possibilities are only as limited as your imagination! Here are a few ideas for things this lets us create:

GitHub Actions提供了一種捕獲和利用事件數(shù)據(jù)的巧妙方法，因此不僅在GitHub中可用。 可能性只限于您的想象！ 以下是一些讓我們創(chuàng)建的東西的想法：

A public-facing issues board, where customers without GitHub accounts can view and give feedback on project issues.

一個(gè)面向公眾的問題委員會，沒有GitHub帳戶的客戶可以在其中查看項(xiàng)目問題并提供反饋。

An automatically-updating RSS feed of new issues, comments, or PRs for any repository.

自動更新任何存儲庫的新問題，評論或PR的RSS feed。

A comments system for static sites, utilizing GitHub issue comments as an input method.

用于靜態(tài)站點(diǎn)的評論系統(tǒng)，利用GitHub發(fā)布評論作為輸入方法。

An awesome 90s guestbook page.

很棒的90年代留言簿頁面。

Did I mention I made a 90s guestbook page? My inner-Geocities-nerd is a little excited.

我是否提到我做了90年代的留言簿頁面 ？ 我內(nèi)心的地質(zhì)書呆子有點(diǎn)興奮。

翻譯自: https://www.freecodecamp.org/news/publishing-github-event-data-with-github-actions-and-pages/

github pages

總結(jié)

以上是生活随笔為你收集整理的github pages_如何使用GitHub Actions和Pages发布GitHub事件数据的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。