GitHub 작업을 사용하여 W3C 표준 워크플로우 단순화

이것은 무엇에 관한 것입니까?W3C 세계에서 ReSpec과 Bikeshed는 웹 표준을 작성하는 데 자주 사용되는 두 가지 도구입니다.ReSpec는 브라우저에서 실행되고 표준 게시에 적합한 정적 HTML 문서를 생성하기 위한 JavaScript 기반 도구입니다.한편, Bikeshed 는 유사한 출력을 만들기 위해 가격 인하 초집합을 처리하는 파이썬 기반 명령행 도구이다.ReSpec에는 CLI도 있습니다.또한 이 두 가지 도구는 W3C 외부에서 사용할 수 있고 사용 중입니다.나는 다른 글에서 ReSpec에 관한 내용을 더 많이 썼다.
왜 컴파일 절차가 필요합니까?ReSpec을 실행하면 브라우저의 HTML 문서가 향상되므로 특별한 도구나 종속성이 필요 없으며 ReSpec 문서는 GitHub 페이지에서 직접 관리할 수 있습니다.Bikeshed는 특수한 텍스트 형식을 사용하기 때문에 컴파일 절차가 없으면 직접 관리할 수 없습니다.그러나 ReSpec이 실행될 때 모든 작업을 수행하기 때문에 캐시 작업이 잘 이루어지더라도 ReSpec 문서의 로딩 속도가 느립니다.따라서 Bikeshed처럼 CLI를 사용하여 ReSpec 문서를 컴파일하고 정적 HTML 출력을 만든 다음 GitHub 페이지에 배치하는 경우도 있습니다.
왜 행동을 취해야 합니까?W3C 표준 생태계는 매우 크다. 많은 저장소들은 Travis, GitHub 조작 등을 사용하여 자신의 작업 흐름을 설정하여 그 규범을 구축하고 검증하며 GitHub 페이지나 W3C에 배치한다.이것은 파편화되고 모든 작업 흐름을 유지하기 어려울 것이다.그래서 저는 Spec Prod라고 불리는 GitHub 작업을 만들기로 했습니다. 모든 규범에 따라 사용할 수 있습니다. 아주 적은 노력만 하면 됩니다.

이 동작은 무슨 작용이 있습니까?

워크플로우에서 설정하면 저장소가 Bikeshed 또는 ReSpec 를 사용하는지 결정하고 적절한 도구를 사용하여 일반 HTML 문서를 생성합니다.
그리고 W3C 태그 인증기와 같은 각종 인증기를 실행하고 끊어진 하이퍼링크를 검사합니다.이것은 일종의 검사이기 때문에 우리는 양식이 잘못된 청구서를 받아들이지 않는다.
요청을 병합하면 생성된 HTML 문서를 GitHub 페이지에 배치할 수 있습니다.적당한 때에 규범을 W3C 사이트에 배치할 수도 있다.보셔도 됩니다sample run.

행동을 세우다

이 절에서 나는 내가 어떻게 이 행동을 발전시켰는지 나눌 것이다. 나는 네가 나의 경험에서 뭔가를 흡수할 수 있기를 바란다.

복합 동작

GitHub 작업은 최근에 "복합"작업을 지원하기 시작했기 때문에 시도하고 싶습니다.간단히 말하면, 여러 개의 작은 프로그램/스크립트를 작성하고, 작업 흐름의 단계를 실행할 때 하나씩 실행할 수 있습니다.GitHub단에서 복합 동작은 아직 해야 할 일이 있다. 예를 들어 UI 개선과 조건 절차 집행 등이다. 그러나 나의 용례에 있어서 그것은 이미 충분하고 해커도 있다.
작업 중의 분리 단계(워크플로가 아님)에 대해 group 명령을 사용하기로 결정했습니다.따라서 내 행동의 모든 단계는 접을 수 있는 부분에 포장된다.

# action.yml
- run: |
    echo "::group::Step 1"
    run-script-for-step-1
    echo "::endgroup::"
  shell: bash
- run: |
    echo "::group::Step 2"
    run-script-for-step-1
    echo "::endgroup::"
  shell: bash

조건 실행에 대해 스크립트는 이 절차를 실행할 필요가 없으면 exit(0) 를 실행합니다.See example .
이것은 좀 보기 싫지만 매우 유용하다.

올바른 언어 선택

저는 JavaScript를 좋아합니다.하지만 이 동작을 위해 나는 Bash로 쓰기로 결정했다.사실이 증명하듯이bash는 특히 문자열 처리와 오류 처리에 있어 통제력을 잃기 쉽다.따라서 대부분의 작업을 완료한 후 JavaScript로 다시 작성하기로 결정했습니다.어떤 부분은 여전히 즐거워하고 있는데, 아마도 아름다운 추억을 위해서일 것이다.Bash는 실제로 순차 명령을 실행하기에 매우 적합합니다.
번역을 제외하고는 동작에 있어서 너무 많은 노력을 필요로 하지 않는다.나는 어쩔 수 없이 통화 방식을 바꾸었다. 예를 들면:

# action.yml
- ${{ github.action_path }}/build.sh
+ node ${{ github.action_path }}/build.sh

좋은 기본 입력 선택

좋은 GitHub 작업 (또는 도구) 에는 기본 동작이 있어야 합니다.입력을 checkout action 에 전달하지 않았더라도 원하는 작업을 수행합니다. 지점/인용을 검사합니다. 좋은 도구는 기본 동작과 낮은 학습 곡선을 가지고 있어야 합니다.
Spec Prod 작업에는 아무런 입력도 필요하지 않습니다.기본적으로 문서를 구축하고 검증합니다.GitHub 페이지 분기에도 배치하시겠습니까?브랜치 이름을 지정합니다.W3C에 배치하시겠습니까?증명하다PRS에 배치해야 합니까?불가능하므로 요청이 없는 한 PRS의 모든 배포를 비활성화합니다.

덮어쓰기 허용

기본 행위는 항상 취할 수 있는 것이 아니며, 소프트웨어는 필요할 때 충분히 유연해야 한다.따라서 Spec Prod 작업을 통해 비헤이비어를 변경할 수도 있습니다.검증기를 실행하고 싶지 않습니까?싫다고 해.입력 파일에 공통 이름이 없습니까?지정합니다.

사전 처리 단계 추가

한 번에 모든 입력을 미리 처리하고 다른 단계로 전달할 수 있는 다단계 작업의 경우 도움이 됩니다.이 건의는 다른 상황에서도 적용된다. 관심사 분리 문제에 부딪히지 않는다면.
GitHub 작업에서 모든 입력이 키 값이 맞기 때문에 문자열화된 JSON 값을 입력하는 것이 멋있지 않기 때문에 나는 입력 키의 종류를 접두사로 하고 검증되고 구조화된 JSON을 입력으로 내부 절차에 전달하기로 결정했다.따라서 일반 키 값 입력:

- uses: sidvishnoi/spec-prod@v1
  with:
    W3C_ECHIDNA_TOKEN: SECRET
    W3C_MANIFEST_URL: URL
    W3C_WG_DECISION_URL: ANOTHER_URL

다음을 수행합니다.

const inputs = {
  // ...
  deploy: {
    w3c: {
      token: "SECRET",
      manifest: "URL",
      decisionUrl: "ANOTHER_URL",
    },
  },
};

우리는 필요한 입력을 한 걸음 전달하기만 하면 된다.

- run: node deploy-w3c.js
  env:
    INPUTS_DEPLOY: ${{ toJson(fromJson(steps.prepare.outputs.all).deploy.w3c) }}

그 밖에 입력 이름은 충분한 묘사성을 가져야 하며, 사용자는 항상 완전한 문서를 읽어서 무슨 일이 일어났는지 이해할 필요가 없다.그래서 나는 W3C_TOKEN 이 아니라 W3C_ECHIDNA_TOKEN 을 사용했다. 왜냐하면 영패는 Echidna 를 통해 얻었기 때문이다.

단순성 유지 - 의존성 없음

개인적으로 나는 필요하지 않으면 구축 절차를 좋아하지 않는다.나는 TypeScript를 좋아하지만, 이 동작을 TypeScript에서 작성하지 않았습니다. 왜냐하면 불필요한 (열처리) 구축 절차가 있는 것 같기 때문입니다.반대로 나는 // @ts-check 주석과 JSDC 주석을 사용하여 편집기에 검사/제시 코드를 입력했다.그것은 일을 아주 잘한다.
그 밖에 저는 Actions 패키지나 다른 node_모듈을 사용하지 않고 필요에 따라 자신의 node_모듈을 만들기로 했습니다.이것은 초고수확은 아니지만, 약간의 즐거움은 매우 좋다.너는 항상 npm가 필요하지 않다.복사 붙여넣기는 때때로 효과가 좋다: 비교this와this.그 밖에 변호를 위해 저originally는 Bash에 모든 동작을 썼습니다. Bash에서 npm는 한 가지 일이 아닙니다.

GitHub 페이지로 배포

GitHub 작업을 사용하여 GitHub 페이지에 배치한 경우 peaceiris/actions-gh-pages이것은 아주 좋은 동작입니다. 좋습니다.
하지만 함정이 하나 있다.GitHub 복합 작업에서는 다른 GitHub 작업을 한 단계로 실행할 수 없습니다.그것은 머지않아 지지를 받을 것이다. 이것은 많은 기회를 가져올 것이다.또한 다른 사람을 신뢰하는 코드가 항상 안전하지는 않습니다. 특히 GitHub 액세스 영패를 전달할 때.
이러한 지원은 고려하지 않고 GitHub 페이지 배포를 지원해야 합니다.그래서 나는 스스로 다시 쓰기로 결정했다.나는 효과적인 해결 방안을 생각해 내는 데 대략 60 lines to Bash 시간이 걸렸다.그리고 더 많은 검증과 로그 기록을 포함하는 근100 line rewrite in JS마음대로 복사해서 붙여넣으세요.피드백을 환영합니다!

테스트

테스트는 현재 GitHub 작업 중 가장 취약한 부분입니다.간단한 단원 테스트를 제외하고 동작을 테스트하는 유일한 방법은 그것을 밀어서 PRS/Committes를 test repository로 보내는 것이다.이것 또한 많은 테스트가 제출을 통해 실행된다는 것을 의미한다. 예를 들어 "일하세요, 지금 일합니까? 완성했습니다. 완성된 것 같습니다. 왜 일을 하지 않습니까!"기다리다
일부 부분에 대해 나는 테스트 입력이 있는 절차를 실행하기 위해 로컬 환경을 만들었지만, 이것은 여전히 매우 번거롭다.

다음은 뭐예요?

이 작업을 사용할 수 있는 저장소로 PRS를 보낼 것입니다.내가 여가 시간이 있을 때, 나는 많은 open issues 일을 해야 한다.기부를 환영합니다!

sidvishnoi 회사 / 규범 제품

GitHub는 GitHub 페이지 또는 W3C에 응답/비키시 사양을 구축하고 출력을 검증하여 게시하는 데 사용됩니다.