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上工作的團隊依靠事件數據進行協作。 記錄為問題，請求和注釋的數據對于理解項目至關重要。

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的普遍可用性，我們就有機會以編程方式訪問并在我們的存儲庫中保存GitHub事件數據。 使數據成為存儲庫本身的一部分是將其保存在GitHub之外的一種方法。 它還使我們能夠在前端網站(例如GitHub Pages)上顯示數據。

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

而且，如果您像我一樣，可以將GitHub問題評論變成一個很棒的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事件數據-只需一個工作流文件。 為了說明該過程，我將帶您瀏覽使我的留言簿更加生動的工作流代碼 。

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

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

訪問GitHub事件數據 (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工作流在具有某些默認環境變量的環境中運行。 此處提供了許多方便的信息，包括事件數據。 訪問事件數據的最完整方法是使用$GITHUB_EVENT_PATH變量，即帶有完整JSON事件有效負載的文件路徑。

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.

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

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:

大多數事件數據也可以通過github.event上下文變量獲得，而無需解析JSON。 可以使用點表示法來訪問這些字段，如下面的示例所示，其中我獲取了相同的注釋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:

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

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變量很容易訪問數據，但是它們是短暫的。 每次運行都會重新創建工作流環境，甚至在一個步驟中設置的Shell變量也不會保留到其他步驟。 要持久保存捕獲的數據，您有兩個選擇：使用構件，或將其提交到存儲庫。

保留事件數據：使用工件 (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:

使用工件，您可以在工作流作業之間保留數據，而無需將其提交到存儲庫。 例如，當您希望在將數據放置到更永久的位置之前進行轉換或合并時，這非常方便。 有必要在工作流作業之間保留數據，因為：

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)

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

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 。 您可以使用這些操作使文件可用于同一工作流程中的其他作業。 有關完整示例，請參見工作流中作業之間的數據傳遞 。

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包含關鍵字的說明 。 上載的文件以.zip格式保存。 同一工作流運行中的另一個作業可以在另一個步驟中使用download-artifact操作來利用數據。

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

您也可以在工作流運行頁面上，在存儲庫的“操作”選項卡下手動下載存檔。

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

在作業之間保留工作流數據不會對存儲庫文件進行任何更改，因為生成的工件僅在工作流環境中有效。

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.

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

保留事件數據：將工作流文件推送到存儲庫 (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.

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

在工作流程中創建文件 (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變量中捕獲的事件數據轉換為適當的文件，使用shell參數擴展中的替換項來清理用戶輸入并將換行符轉換為段落。 之前，我寫過關于為什么應謹慎對待用戶輸入的文章 。

- 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并將其輸出帶有>定向到新文件，事件數據將轉換為HTML文件，該文件以注釋ID號命名，其中包含捕獲的事件數據。 格式化后，它看起來像：

<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.

使用注釋時，使用注釋ID命名文件的一個效果是，具有相同ID的新文件將覆蓋前一個文件。 這對于留言簿非常方便，因為它允許對注釋的任何編輯來替換原始注釋文件。

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之類的靜態網站生成器，則可以構建Markdown格式的文件，并將其粘貼在content/文件夾中，其余的工作將由常規網站進行。

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.

對于我的簡單留言簿，我還有一個額外的步驟將單個注釋文件整合到頁面中。 每次運行時，它都會用header.html部分( > )覆蓋現有的index.html ，然后以降序查找并附加( >> )所有注釋文件的內容，最后將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操作與克隆存儲庫不太一樣，因此在撰寫本文時，仍有一些問題需要解決。 需要幾個額外的步驟才能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.

遠程，實際上是我們的存儲庫，是使用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.

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

顯示事件數據 (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需要一個Personal Access Token來觸發Pages網站構建。

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."

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

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.

要使操作能夠觸發Pages網站構建，您需要創建一個個人訪問令牌。 該令牌可以作為機密存儲在存儲庫設置中，并代替默認的secrets.GITHUB_TOKEN變量傳遞到工作流中。 我在這篇文章中寫了更多有關Actions環境和變量的文章 。

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.

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

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:

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

- 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.

這樣可以確保工作流程的最后一步可以構建和部署更新的站點。

不再有事件數據范圍 (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提供了一種捕獲和利用事件數據的巧妙方法，因此不僅在GitHub中可用。 可能性只限于您的想象！ 以下是一些讓我們創建的東西的想法：

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

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

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.

用于靜態站點的評論系統，利用GitHub發布評論作為輸入方法。

An awesome 90s guestbook page.

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

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

我是否提到我做了90年代的留言簿頁面 ？ 我內心的地質書呆子有點興奮。

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

github pages

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。