Computer >> 컴퓨터 >  >> 프로그램 작성 >> BASH 프로그래밍

GitHub 작업 및 페이지를 사용하여 GitHub 이벤트 데이터를 게시하는 방법

GitHub에서 작업하는 팀은 이벤트 데이터를 사용하여 협업합니다. 이슈, 풀 리퀘스트, 댓글로 기록된 데이터는 프로젝트를 이해하는 데 매우 중요합니다.

GitHub Actions의 일반 가용성으로 리포지토리의 GitHub 이벤트 데이터에 프로그래밍 방식으로 액세스하고 보존할 수 있습니다. 데이터를 저장소 자체의 일부로 만드는 것은 GitHub 외부에서 데이터를 보존하는 방법입니다. 또한 GitHub 페이지와 같이 전면 웹사이트에 데이터를 표시할 수 있는 기능도 제공합니다.

그리고 저와 같다면 GitHub 이슈 댓글을 멋진 90년대 방명록 페이지로 바꿀 수 있습니다.

사용법에 관계없이 기본 개념은 동일합니다. 하나의 워크플로 파일로 작업을 사용하여 GitHub 이벤트 데이터에 액세스, 보존 및 표시할 수 있습니다. 프로세스를 설명하기 위해 내 방명록을 빛나게 하는 워크플로 코드를 안내해 드리겠습니다.

워크플로가 트리거되는 방법을 포함하여 GitHub 작업에 대한 소개를 보려면 GitHub 작업을 사용한 경량의 도구에 구애받지 않는 CI/CD 흐름을 참조하세요.

GitHub 이벤트 데이터 액세스

작업 워크플로는 일부 기본 환경 변수가 있는 환경에서 실행됩니다. 이벤트 데이터를 비롯한 많은 편리한 정보를 얻을 수 있습니다. 이벤트 데이터에 액세스하는 가장 완벽한 방법은 $GITHUB_EVENT_PATH를 사용하는 것입니다. 변수, 완전한 JSON 이벤트 페이로드가 있는 파일의 경로입니다.

확장된 경로는 /home/runner/work/_temp/_github_workflow/event.json과 같습니다. 해당 데이터는 웹훅 이벤트에 해당합니다. GitHub REST API 이벤트 유형 및 페이로드에서 웹훅 이벤트 데이터에 대한 설명서를 찾을 수 있습니다. 워크플로 환경에서 JSON 데이터를 사용할 수 있도록 하려면 jq와 같은 도구를 사용할 수 있습니다. 이벤트 데이터를 구문 분석하여 환경 변수에 넣습니다.

아래에서 문제 댓글 이벤트에서 댓글 ID를 가져옵니다.

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

대부분의 이벤트 데이터는 github.event를 통해서도 사용할 수 있습니다. JSON을 구문 분석할 필요 없이 컨텍스트 변수. 동일한 주석 ID를 가져오는 아래 예에서와 같이 필드는 점 표기법을 사용하여 액세스됩니다.

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

내 방명록의 경우 사용자의 핸들과 날짜 및 시간으로 항목을 표시하고 싶습니다. 다음과 같이 이 이벤트 데이터를 캡처할 수 있습니다.

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

셸 변수는 데이터 액세스에 편리하지만 일시적입니다. 워크플로 환경은 실행할 때마다 새로 생성되며 한 단계에서 설정된 셸 변수라도 다른 단계에서는 유지되지 않습니다. 캡처한 데이터를 유지하려면 아티팩트를 사용하거나 저장소에 커밋하는 두 가지 옵션이 있습니다.

이벤트 데이터 보존:아티팩트 사용

아티팩트를 사용하면 리포지토리에 커밋하지 않고 워크플로 작업 간에 데이터를 유지할 수 있습니다. 예를 들어 데이터를 더 영구적인 위치에 넣기 전에 데이터를 변환하거나 통합하려는 경우에 유용합니다. 다음과 같은 이유로 워크플로 작업 간에 데이터를 유지해야 합니다.

워크플로의 각 작업은 가상 환경의 새로운 인스턴스에서 실행됩니다. 작업이 완료되면 러너는 가상 환경의 인스턴스를 종료하고 삭제합니다. (아티팩트를 사용하여 워크플로 데이터 유지)

아티팩트 사용을 지원하는 두 가지 작업:upload-artifact 및 download-artifact . 이러한 작업을 사용하여 동일한 워크플로의 다른 작업에서 파일을 사용할 수 있도록 할 수 있습니다. 전체 예는 워크플로에서 작업 간에 데이터 전달을 참조하세요.

upload-artifact 액션의 action.yml 키워드에 대한 설명이 포함되어 있습니다. 업로드된 파일은 .zip에 저장됩니다. 체재. 동일한 워크플로 실행의 다른 작업은 download-artifact를 사용할 수 있습니다. 다른 단계에서 데이터를 활용하기 위한 조치입니다.

저장소의 작업 탭 아래에 있는 워크플로 실행 페이지에서 아카이브를 수동으로 다운로드할 수도 있습니다.

작업 간에 워크플로 데이터를 유지하면 생성된 아티팩트가 워크플로 환경에서만 라이브이므로 리포지토리 파일이 변경되지 않습니다.

개인적으로 쉘 환경에서 작업하는 것이 편하기 때문에 아티팩트에 대한 사용 사례가 좁다는 것을 알지만 언급하지 않기를 꺼려했습니다. 작업 간에 데이터를 전달하는 것 외에도 .zip을 생성하는 데 유용할 수 있습니다. 예를 들어 테스트 출력 데이터의 형식 아카이브. 내 방명록 예제의 경우, 한 작업에서 필요한 모든 단계를 단순히 실행하여 작업 간에 데이터를 전달할 필요가 없었습니다.

이벤트 데이터 보존:워크플로 파일을 저장소로 푸시

워크플로에서 캡처한 데이터를 리포지토리 자체에 보존하려면 이 데이터를 Git 리포지토리에 추가하고 푸시해야 합니다. 데이터로 새 파일을 만들거나 셸 명령을 사용하여 기존 파일에 데이터를 추가하여 워크플로에서 이 작업을 수행할 수 있습니다.

워크플로에서 파일 만들기

워크플로에서 리포지토리 파일로 작업하려면 checkout을 사용하세요. 작업할 사본을 먼저 얻기 위한 조치:

- uses: actions/checkout@master
  with:
    fetch-depth: 1

내 방명록에 주석을 추가하기 위해 셸 변수에 캡처된 이벤트 데이터를 적절한 파일로 변환하고 셸 매개변수 확장의 대체를 사용하여 사용자 입력을 삭제하고 줄 바꿈을 단락으로 변환합니다. 사용자 입력을 신중하게 처리해야 하는 이유에 대해 이전에 쓴 적이 있습니다.

- name: Turn comment into file
  run: |
    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=comments

    printf '%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

printf를 사용하여 >로 출력을 지시합니다. 새 파일로 변환하면 이벤트 데이터가 캡처된 이벤트 데이터를 포함하는 주석 ID 번호로 명명된 HTML 파일로 변환됩니다. 형식은 다음과 같습니다.

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

주석으로 작업할 때 주석 ID를 사용하여 파일 이름을 지정하면 동일한 ID를 가진 새 파일이 이전 파일을 덮어씁니다. 댓글을 수정하면 원본 댓글 파일을 대체할 수 있으므로 방명록에 유용합니다.

Hugo와 같은 정적 사이트 생성기를 사용하는 경우 Markdown 형식 파일을 빌드하여 content/에 추가할 수 있습니다. 폴더에 있고 나머지는 일반 사이트 빌드에서 처리합니다.

내 단순한 방명록의 경우 개별 댓글 파일을 페이지로 통합하는 추가 단계가 있습니다. 실행할 때마다 기존 index.html을 덮어씁니다. header.html 사용 부분(> ), 찾아 추가(>> ) 모든 주석 파일의 내용을 내림차순으로 만들고 마지막으로 footer.html을 추가합니다. 페이지를 끝내는 부분입니다.

- name: Assemble page
  run: |
    cat header.html > index.html
    find comments/ -name "*.html" | sort -r | xargs -I % cat % >> index.html
    cat footer.html >> index.html

저장소에 변경 사항 커밋

checkout 이후 작업은 리포지토리를 복제하는 것과 완전히 동일하지 않습니다. 작성 당시에는 여전히 해결해야 할 몇 가지 문제가 있습니다. pull에는 몇 가지 추가 단계가 필요합니다. , checkout , 성공적으로 push master로 다시 변경 하지만 이것은 셸에서 아주 간단하게 수행됩니다.

다음은 워크플로에서 변경한 내용을 저장소의 master에 다시 추가, 커밋 및 푸시하는 단계입니다. 지점.

- name: Push changes to repo
  run: |
    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 master
    git add .
    git status
    git commit -am "Add new comment"
    git push ${REMOTE} master

원격, 실제로 우리의 저장소는 github.repository를 사용하여 지정됩니다. 컨텍스트 변수. 워크플로가 마스터로 푸시되도록 하려면 secrets.GITHUB_TOKEN을 사용합니다. 변수.

워크플로 환경은 반짝거리고 새로 생겨났기 때문에 Git을 구성해야 합니다. 위의 예에서는 github.actor를 사용했습니다. 워크플로를 시작하는 계정의 사용자 이름을 입력하는 컨텍스트 변수입니다. 이메일은 기본 noreply를 사용하여 유사하게 구성됩니다. GitHub 이메일 주소.

이벤트 데이터 표시

2019년 11월 6일 수정:GitHub Actions에서 페이지 사이트 빌드를 트리거하려면 개인 액세스 토큰이 필요합니다.

기본 secrets.GITHUB_TOKEN으로 GitHub 페이지를 사용하는 경우 변수를 사용하고 사이트 생성기가 없으면 워크플로의 리포지토리에 변경 사항을 푸시하면 리포지토리 파일만 업데이트됩니다. GitHub 페이지 빌드는 "사이트 빌드에 문제가 있습니다:페이지 빌드 실패" 오류와 함께 실패합니다.

페이지 사이트 빌드를 트리거하는 작업을 활성화하려면 개인 액세스 토큰을 만들어야 합니다. 이 토큰은 저장소 설정에 비밀로 저장하고 기본 secrets.GITHUB_TOKEN 대신 워크플로에 전달할 수 있습니다. 변하기 쉬운. 이 게시물에서 Actions 환경 및 변수에 대해 자세히 썼습니다.

개인 액세스 토큰을 사용하면 작업 워크플로에 의해 시작된 푸시가 페이지 사이트도 업데이트합니다. 제 방명록에 댓글을 남겨주시면 직접 보실 수 있습니다! 댓글 작성 이벤트는 워크플로를 트리거한 다음 방명록 페이지를 실행하고 업데이트하는 데 약 30초에서 1분 정도 걸립니다.

Hugo를 사용할 때와 같이 변경 사항을 게시하기 위해 사이트 빌드가 필요한 경우 Action에서도 이 작업을 수행할 수 있습니다. 그러나 의도하지 않은 루프 생성을 방지하기 위해 한 작업 워크플로에서 다른 작업을 트리거하지 않습니다. 대신 모든 워크플로에서 실행할 수 있는 Makefile을 사용하여 사이트를 구축하는 프로세스를 처리하는 것이 매우 편리합니다. 필요한 경우 저장소 토큰을 사용하여 워크플로 작업의 마지막 단계로 Makefile 실행을 추가하기만 하면 됩니다.

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

이렇게 하면 워크플로의 마지막 단계에서 업데이트된 사이트를 구축하고 배포할 수 있습니다.

더 이상 이벤트 데이터 지평선이 없습니다.

GitHub Actions는 이벤트 데이터를 캡처하고 활용하는 깔끔한 방법을 제공하므로 GitHub 내에서만 사용할 수 없습니다. 가능성은 당신의 상상만큼만 제한됩니다! 다음은 이를 통해 만들 수 있는 몇 가지 아이디어입니다.

  1. GitHub 계정이 없는 고객이 프로젝트 문제를 보고 피드백을 제공할 수 있는 공개 문제 게시판입니다.
  2. 모든 저장소에 대한 새로운 문제, 의견 또는 PR에 대한 RSS 피드 자동 업데이트
  3. GitHub 이슈 댓글을 입력 방식으로 활용하는 정적 사이트용 댓글 시스템
  4. 멋진 90년대 방명록 페이지입니다.

내가 90년대 방명록 페이지를 만들었다고 언급했습니까? 내 내면의 Geocities-nerd는 약간 흥분합니다.