Circles of Hell עם GitHub Actions (בניית צינור CI/CD עבור פרויקט Java)

לעתים קרובות אני צריך לבנות צינור לבניית פרויקטים בג'אווה. לפעמים זה קוד פתוח ולפעמים לא. לאחרונה החלטתי לנסות להעביר חלק מהמאגרים שלי מ-Travis-CI ו-TeamCity ל-GitHub Actions, וזה מה שיצא מזה.

מה נעשה אוטומטית?

ראשית, אנחנו צריכים פרויקט שנעשה אוטומטית, בואו נעשה אפליקציה קטנה ב-Spring boot/Java 11/Maven. לצורך מאמר זה לא נתעניין כלל בלוגיקת האפליקציה, התשתית מסביב לאפליקציה חשובה לנו, כך שבקר REST API פשוט יספיק לנו.

אתה יכול לראות את המקורות כאן: github.com/antkorwin/github-actions כל שלבי בניית הצינור באים לידי ביטוי בבקשות המשיכה לפרויקט זה.

JIRA ותכנון

כדאי לומר שבדרך כלל אנו משתמשים ב-JIRA כמעקב אחר בעיות, אז בואו ניצור לוח נפרד לפרויקט הזה ונוסיף שם את הבעיות הראשונות:

קצת מאוחר יותר נחזור לאילו דברים מעניינים JIRA ו-GitHub יכולים להציע בשילוב.

אנו הופכים את ההרכבה לאוטומטית של הפרויקט

פרויקט הבדיקה שלנו נבנה באמצעות maven, אז בנייתו די פשוטה, כל מה שאנחנו צריכים זה את החבילה הנקייה של mvn.

כדי לעשות זאת באמצעות Github Actions, נצטרך ליצור במאגר קובץ המתאר את זרימת העבודה שלנו, זה יכול להיעשות עם קובץ yml רגיל, אני לא יכול להגיד שאני אוהב "תכנות yml", אבל מה אנחנו יכולים לעשות - אנו עושים זאת ב-.github/ directory workflow/ file build.yml שבו נתאר את הפעולות בעת בניית ענף המאסטר:

name: Build

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean package -DskipTests

on - זה תיאור של האירוע שבו התסריט שלנו יושק.

ב: pull_request/push - מציין שצריך להפעיל את זרימת העבודה הזו בכל פעם שמתבצעת דחיפה למאסטר ויוצרות בקשות משיכה.

להלן תיאור של המשימות (משרות) ושלבי ביצוע (צעדים) עבור כל משימה.

פועל הלאה - כאן אנחנו יכולים לבחור את מערכת ההפעלה היעד, באופן מפתיע, אתה יכול אפילו לבחור ב-Mac OS, אבל במאגרים פרטיים זה די יקר (בהשוואה ללינוקס).

שימושים מאפשר לך לעשות שימוש חוזר בפעולות אחרות, למשל, באמצעות פעולת actions/setup-java אנו מתקינים את הסביבה עבור Java 11.

באמצעות עם אנו יכולים לציין את הפרמטרים שבאמצעותם אנו מפעילים את הפעולה, בעצם אלו הטיעונים שיועברו לפעולה.

כל מה שנותר הוא להפעיל את בניית הפרויקט עם Maven: run: mvn -B clean package דגל -B אומר שאנחנו צריכים מצב לא אינטראקטיבי כדי שהמאבן לפתע לא ירצה לשאול אותנו משהו

גדול! כעת, בכל פעם שאתה מתחייב למאסטר, בניית הפרויקט מתחילה.

אוטומציה של השקות בדיקה

הרכבה טובה, אבל במציאות, פרויקט יכול להיות מורכב בבטחה, אבל לא לעבוד. לכן, השלב הבא הוא להפוך את ריצות הבדיקה לאוטומטיות. בנוסף, די נוח להסתכל על תוצאות המעבר במבחנים כאשר עושים סקירת יחסי ציבור – יודעים בוודאות שהבדיקות עוברות ואף אחד לא שכח להפעיל את הסניף שלו לפני ביצוע מיזוג.

נערוך בדיקות בעת יצירת בקשת pull ונמזג לתוך המאסטר, ובמקביל נוסיף יצירת דוח על כיסוי קוד.

name: Build

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Verify
        run: mvn -B clean verify
      - name: Test Coverage
        uses: codecov/codecov-action@v1
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

כדי לכסות בדיקות, אני משתמש ב-codecov בשילוב עם תוסף jacoco. ל-codecov יש פעולה משלו, אבל הוא צריך אסימון כדי לעבוד עם בקשת המשיכה שלנו:

${{ secrets.CODECOV_TOKEN }} — אנחנו נראה את הבנייה הזו יותר מפעם אחת, סודות זה מנגנון לאחסון סודות ב-GitHub, נוכל לכתוב שם סיסמאות/אסימונים/מארחים/כתובות אתרים ונתונים נוספים שלא צריכים להיכלל בבסיס הקוד של המאגר.

אתה יכול להוסיף משתנה לסודות בהגדרות המאגר ב- GitHub:

אתה יכול לקבל אסימון ב codecov.io לאחר אישור באמצעות GitHub, כדי להוסיף פרויקט ציבורי, אתה רק צריך לעקוב אחר קישור כזה: שם משתמש GitHub/[שם ריפו]. ניתן להוסיף גם מאגר פרטי; כדי לעשות זאת, עליך לתת זכויות codecov לאפליקציה ב- Github.

הוסף את הפלאגין jacoco לקובץ POM:

<plugin>
	<groupId>org.jacoco</groupId>
	<artifactId>jacoco-maven-plugin</artifactId>
	<version>0.8.4</version>
	<executions>
		<execution>
			<goals>
				<goal>prepare-agent</goal>
			</goals>
		</execution>
		<!-- attached to Maven test phase -->
		<execution>
			<id>report</id>
			<phase>test</phase>
			<goals>
				<goal>report</goal>
			</goals>
		</execution>
	</executions>
</plugin>
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<version>2.22.2</version>
	<configuration>
		<reportFormat>plain</reportFormat>
		<includes>
			<include>**/*Test*.java</include>
			<include>**/*IT*.java</include>
		</includes>
	</configuration>
</plugin>

כעת בוט ה-codecov יזין כל אחת מבקשות המשיכה שלנו ויוסיף גרף שינוי כיסוי:

בואו נוסיף מנתח סטטי

ברוב פרויקטי הקוד הפתוח שלי אני משתמש בענן סונאר לניתוח קוד סטטי, די קל להתחבר ל-travis-ci. אז זה צעד הגיוני במעבר ל-GitHub Actions לעשות את אותו הדבר. שוק האקשן הוא דבר מגניב, אבל הפעם הוא קצת אכזב אותי, כי מתוך הרגל מצאתי את האקשן שהייתי צריך והוספתי אותו לתהליך העבודה. אבל התברר שסונאר אינו תומך בעבודה באמצעות פעולה לניתוח פרויקטים ב-maven או gradle. כמובן שזה כתוב בתיעוד, אבל מי קורא את זה?!

זה לא אפשרי דרך פעולה, אז נעשה את זה דרך התוסף mvn:

name: SonarCloud

on:
  push:
    branches:
      - master
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  sonarcloud:
    runs-on: ubuntu-16.04
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Analyze with SonarCloud
#       set environment variables:
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
#       run sonar maven plugin:
        run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml

SONAR_TOKEN - ניתן להשיג ב sonarcloud.io ואתה צריך לרשום את זה בסודות. GITHUB_TOKEN - זהו אסימון מובנה ש-GitHub מייצר, בעזרתו sonarcloud[bot] יוכל להיכנס ל-Git על מנת להשאיר לנו הודעות בבקשות pull.

Dsonar.projectKey - שם הפרויקט בסונאר, אתה יכול לראות אותו בהגדרות הפרויקט.

דסונר.ארגון - שם הארגון מ-GitHub.

אנו מגישים בקשת משיכה ומחכים ש-sonarcloud[bot] יגיע בתגובות:

ניהול שחרור

ה-build הוגדר, הבדיקות הופעלו, ואנחנו יכולים להוציא מהדורה. בואו נסתכל כיצד פעולות GitHub יכולות להקל בהרבה על ניהול ההפצות.

בעבודה, יש לי פרויקטים שבסיס הקוד שלהם הוא ב-bitbucket (הכל כמו בסיפור ההוא "אני כותב ל-bitbucket במהלך היום, מתחייב ל-GitHub בלילה"). למרבה הצער, ל-bitbucket אין כלי ניהול מהדורות מובנים. זו בעיה, כי עבור כל מהדורה אתה צריך ליצור ידנית עמוד במפגש ולזרוק לשם את כל הפיצ'רים הכלולים במהדורה, לחפש בארמונות המוח, משימות בג'ירה, מתחייבים במאגר. יש הרבה סיכויים לטעות, אפשר לשכוח משהו או להזין משהו שכבר שוחרר בפעם הקודמת, לפעמים פשוט לא ברור למה לסווג בקשת pull - האם זה פיצ'ר או תיקון באג, או בדיקות עריכה, או משהו תשתיתי .

כיצד פעולות GitHub יכולות לעזור לנו? ישנה פעולה מצוינת - מנסח שחרור, זה מאפשר לך להגדיר תבנית קובץ של הערות שחרור כדי להגדיר קטגוריות של בקשות משיכה ולקבץ אותן אוטומטית בקובץ הערות השחרור:

תבנית לדוגמה להגדרת דוח (.github/release-drafter.yml):

name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
  - title: ' New Features'
    labels:
      - 'type:features'
# в эту категорию собираем все PR с меткой type:features

  - title: ' Bugs Fixes'
    labels:
      - 'type:fix'
# аналогично для метки type:fix и т.д.

  - title: ' Documentation'
    labels:
      - 'type:documentation'

  - title: ' Configuration'
    labels:
      - 'type:config'

change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
  ## Changes
  $CHANGES

הוסף סקריפט כדי ליצור מהדורת טיוטה (.github/workflows/release-draft.yml):

name: "Create draft release"

on:
  push:
    branches:
      - master

jobs:
  update_draft_release:
    runs-on: ubuntu-18.04
    steps:
      - uses: release-drafter/release-drafter@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

כל בקשות המשיכה מעתה ואילך ייאספו בהערות שחרור באופן אוטומטי - קסם!

כאן עלולה להתעורר השאלה: מה אם המפתחים ישכחו לשים תגים ב-PR? אחר כך לא ברור באיזו קטגוריה להכניס אותו, ושוב תצטרכו לטפל בזה באופן ידני, עם כל יחסי ציבור בנפרד. כדי לתקן בעיה זו, אנו יכולים להשתמש בפעולה אחרת - מאמת תווית - היא בודקת נוכחות של תגים בבקשת המשיכה. אם אין תגים נדרשים, הבדיקה תיכשל ונראה הודעה על כך בבקשת המשיכה שלנו.

name: "Verify type labels"

on:
  pull_request:
    types: [opened, labeled, unlabeled, synchronize]

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: zwaldowski/match-label-action@v2
        with:
          allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'

כעת יש לסמן כל בקשת משיכה באחת מהתגים: type:fix, type:features, type:documentation, type:tests, type:config.

הערה אוטומטית של בקשות משיכה

מכיוון שנגענו בנושא כמו עבודה אפקטיבית עם בקשות משיכה, כדאי לדבר על פעולה כזו כמו תיוג, היא שמה תגיות ב-PR על סמך אילו קבצים שונו. לדוגמה, אנו יכולים לסמן כ-[build] כל בקשת משיכה המכילה שינויים בספרייה .github/workflow.

חיבור זה די פשוט:

name: "Auto-assign themes to PR"

on:
  - pull_request

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

אנחנו צריכים גם קובץ המתאר את ההתכתבות בין ספריות הפרויקט ונושאי בקשת המשיכה:

theme:build:
  - ".github/**"
  - "pom.xml"
  - ".travis.yml"
  - ".gitignore"
  - "Dockerfile"

theme:code:
  - "src/main/*"

theme:tests:
  - "src/test/*"

theme:documentation:
  - "docs/**"

theme:TRASH:
  - ".idea/**"
  - "target/**"

לא הצלחתי לשייך את הפעולה שממקמת אוטומטית תוויות בבקשות משיכה לפעולה שבודקת קיומן של תוויות נדרשות; match-label לא רוצה לראות את התוויות שנוספו על ידי הבוט. נראה שקל יותר לכתוב פעולה משלך המשלבת את שני השלבים. אבל אפילו בצורה זו זה די נוח לשימוש; אתה צריך לבחור תווית מהרשימה בעת יצירת בקשת משיכה.

הגיע הזמן לפרוס

ניסיתי מספר אפשרויות פריסה דרך GitHub Actions (דרך ssh, דרך scp ושימוש ב-docer-hub), ואני יכול לומר שככל הנראה, תמצא דרך להעלות את הבינארי לשרת, לא משנה כמה הצינור שלך עקום הוא.

אהבתי את האפשרות לשמור את כל התשתית במקום אחד, אז בואו נסתכל כיצד לפרוס ל-GitHub Packages (זהו מאגר לתוכן בינארי, npm, jar, docker).

סקריפט לבניית תמונת docker ופרסום שלה בחבילות GitHub:

name: Deploy docker image

on:
  push:
    branches:
      - 'master'

jobs:

  build_docker_image:
    runs-on: ubuntu-18.04
    steps:

#     Build JAR:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean compile package -DskipTests

#     Set global environment variables:
      - name: set global env
        id: global_env
        run: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"

#     Build Docker image:
      - name: Build and tag image
        run: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - name: Docker login
        run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publish image to github package repository:
      - name: Publish image
        env:
          IMAGE_NAME: $GITHUB_REPOSITORY
        run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"

ראשית, עלינו לבנות את קובץ ה-JAR של האפליקציה שלנו, ולאחר מכן אנו מחשבים את הנתיב ל-GitHub docker registry ואת שם התמונה שלנו. יש כאן כמה טריקים שעדיין לא נתקלנו בהם:

• בנייה כמו: echo "::set-output name=NAME::VALUE" מאפשרת לך להגדיר את הערך של משתנה בשלב הנוכחי, כך שניתן יהיה לקרוא אותו בכל שאר השלבים.
• אתה יכול לקבל את הערך של המשתנה שהוגדר בשלב הקודם דרך המזהה של שלב זה: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• המשתנה הסטנדרטי GITHUB_REPOSITORY מאחסן את שם המאגר והבעלים שלו ("בעלים/שם ריפו"). על מנת לחתוך הכל מהשורה הזו מלבד שם המאגר, נשתמש בתחביר bash: ${GITHUB_REPOSITORY#*/}

בשלב הבא עלינו לבנות את תמונת הדוקר:

docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"

היכנס לרישום:

docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

ופרסם את התמונה למאגר החבילות של GitHub:

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

על מנת לציין את גרסת התמונה, אנו משתמשים בספרות הראשונות מה-SHA hash של ה-commit - GITHUB_SHA יש כאן גם ניואנסים, אם תבצע בנייה כזו לא רק בעת מיזוג לתוך מאסטר, אלא גם על פי יצירת בקשת המשיכה אירוע, אז ייתכן ש-SHA לא יתאים ל-hash שאנו רואים בהיסטוריית git, מכיוון שפעולת ה-actions/checkout מייצרת hash ייחודי משלה כדי למנוע פעולות מבוי סתום ב-PR.

אם הכל הסתדר כשורה, ואז פתיחת מדור החבילות (https://github.com/antkorwin/github-actions/packages) במאגר, תראה תמונת docker חדשה:

שם תוכל גם לראות רשימה של גרסאות של תמונת ה-docker.

כל מה שנותר הוא להגדיר את השרת שלנו לעבוד עם הרישום הזה ולהפעיל מחדש את השירות. אני כנראה אדבר על איך לעשות את זה דרך systemd בפעם אחרת.

ניטור

בואו נסתכל על אפשרות פשוטה כיצד לבצע בדיקת תקינות עבור האפליקציה שלנו באמצעות GitHub Actions. לאפליקציית האתחול שלנו יש מפעיל, אז אנחנו אפילו לא צריכים לכתוב API כדי לבדוק את הסטטוס שלו; כבר עשינו הכל בשביל העצלנים. אתה רק צריך למשוך את המארח: SERVER-URL:PORT/actuator/health

$ curl -v 127.0.0.1:8080/actuator/health

> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*

< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT

{"status":"UP"}

כל מה שאנחנו צריכים זה לכתוב משימה לבדוק את השרת באמצעות cron, ואם פתאום הוא לא עונה לנו, אז נשלח הודעה באמצעות מברק.

ראשית, בואו נבין כיצד להפעיל זרימת עבודה של cron:

on:
  schedule:
    - cron:  '*/5 * * * *'

זה פשוט, אני אפילו לא מאמין שב-Github אתה יכול ליצור אירועים שלא מתאימים בכלל ל-webhooks. פרטים בתיעוד: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

בואו נבדוק את מצב השרת באופן ידני באמצעות curl:

jobs:
  ping:
    runs-on: ubuntu-18.04
    steps:

      - name: curl actuator
        id: ping
        run: |
          echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"

      - name: health check
        run: |
          if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
            echo "health check is failed"
            exit 1
          fi
          echo "It's OK"

ראשית, אנו שומרים למשתנה את מה שהשרת הגיב לבקשה, בשלב הבא בודקים שהסטטוס הוא UP ואם זה לא המקרה, אז נצא עם שגיאה. אם אתה צריך "להציף" פעולה עם הידיים שלך, אז צא מ- 1 - נשק מתאים.

  - name: send alert in telegram
    if: ${{ failure() }}
    uses: appleboy/telegram-action@master
    with:
      to: ${{ secrets.TELEGRAM_TO }}
      token: ${{ secrets.TELEGRAM_TOKEN }}
      message: |
        Health check of the:
        ${{secrets.SERVER_HOST}}/api/actuator/health
        failed with the result:
        ${{ steps.ping.outputs.status }}

אנו שולחים לטלגרם רק אם הפעולה נכשלה בשלב הקודם. כדי לשלוח הודעה אנו משתמשים ב-appleboy/telegram-action; תוכל לקרוא על איך להשיג אסימון בוט ומזהה צ'אט בתיעוד: github.com/appleboy/telegram-action

אל תשכח לכתוב בסודות ב-Github: URL לשרת ואסימונים לבוט הטלגרם.

רצועת בונוס - JIRA לעצלנים

הבטחתי שנחזור ל-JIRA, וחזרנו. מאות פעמים ראיתי מצב בסטנד-אפים כאשר מפתחים עשו פיצ'ר, מיזגו סניף, אבל שכחתי לגרור את הנושא ל-JIRA. כמובן, אם כל זה היה נעשה במקום אחד, זה היה קל יותר, אבל למעשה אנחנו כותבים קוד ב-IDE, ממזגים סניפים לתוך bitbucket או GitHub, ואז גוררים את המשימות לתוך Jira, בשביל זה אנחנו צריכים לפתוח חלונות חדשים , לפעמים להיכנס שוב וכו'. כאשר אתה זוכר היטב מה אתה צריך לעשות הלאה, אז אין טעם לפתוח את הלוח שוב. כתוצאה מכך, בבוקר בסטנדאפ אתה צריך להקדיש זמן לעדכון לוח המשימות.

GitHub גם יעזור לנו במשימה השגרתית הזו; בתור התחלה, אנו יכולים לגרור בעיות אוטומטית לעמודת code_review כאשר אנו שולחים בקשת משיכה. כל מה שאתה צריך לעשות הוא לעקוב אחר מוסכמות שמות הסניפים:

[имя проекта]-[номер таска]-название

לדוגמה, אם מפתח הפרויקט "GitHub Actions" הוא GA, אז GA-8-jira-bot יכול להיות ענף ליישום משימת GA-8.

האינטגרציה עם JIRA עובדת דרך פעולות מאטלסיאן, הן לא מושלמות, אני חייב לומר שחלקן לא עבדו לי בכלל. אבל נדון רק באלה שבהחלט עובדים ונמצאים בשימוש פעיל.

ראשית עליך להיכנס ל-JIRA באמצעות הפעולה: atlassian/gajira-login

jobs:
  build:
    runs-on: ubuntu-latest
    name: Jira Workflow
    steps:
      - name: Login
        uses: atlassian/gajira-login@master
        env:
          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
          JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

כדי לעשות זאת, אתה צריך לקבל אסימון ב-JIRA, איך לעשות זאת מתואר כאן: confluence.atlassian.com/cloud/api-tokens-938839638.html

אנו מחלצים את מזהה המשימה משם הסניף:

  - name: Find Issue
    id: find_issue
    shell: bash
    run: |
      echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
      echo brach name: $GITHUB_HEAD_REF
      echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'

  - name: Check Issue
    shell: bash
    run: |
      if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
        echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
        exit 1
      fi
      echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}

אם אתה מחפש בשוק GitHub, אתה יכול למצוא פעולה עבור המשימה הזו, אבל הייתי צריך לכתוב את אותו הדבר באמצעות grep באמצעות שם הסניף, כי הפעולה הזו מאטלסיאן לא רצתה לעבוד על הפרויקט שלי בשום אופן , כדי להבין מה לא בסדר שם - יותר זמן מאשר לעשות את אותו הדבר עם הידיים.

כל מה שנותר הוא להעביר את המשימה לעמודה "סקירת קוד" בעת יצירת בקשת משיכה:

  - name: Transition issue
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

ישנה פעולה מיוחדת לכך ב-GitHub, כל מה שהוא צריך זה את מזהה הבעיה שהושג בשלב הקודם וההרשאה ב-JIRA שעשינו למעלה.

באותו אופן, אתה יכול לגרור משימות בעת מיזוג לתוך המאסטר, ואירועים אחרים מזרימת העבודה של GitHub. באופן כללי, הכל תלוי בדמיון וברצון שלכם להפוך תהליכים שגרתיים לאוטומטיים.

ממצאים

אם תסתכל על דיאגרמת DEVOPS הקלאסי, כיסינו את כל השלבים, פרט אולי לתפעול, אני חושב שאם תנסה, תוכל למצוא פעולה כלשהי בשוק לאינטגרציה עם מערכת ה-Help-Desk, אז נניח שהצינור התהפך להיות יסודי וניתן להסיק מסקנות על סמך השימוש בו.

יתרונות:

• שוק עם פעולות מוכנות לכל אירוע, זה מאוד מגניב. ברובם תוכלו גם להסתכל בקוד המקור כדי להבין כיצד לפתור בעיה דומה או לפרסם בקשת תכונה למחבר ישירות במאגר GitHub.
• בחירת פלטפורמת היעד להרכבה: לינוקס, mac os, windows היא תכונה מעניינת למדי.
• חבילות Github זה דבר נהדר, נוח לשמור את כל התשתית במקום אחד, לא צריך לגלוש דרך חלונות שונים, הכל נמצא ברדיוס של לחיצת עכבר אחת או שתיים ומשולב בצורה מושלמת עם GitHub Actions. תמיכה ברישום Docker בגרסה החינמית היא גם יתרון טוב.
• GitHub מסתיר סודות ביומני בנייה, כך שהשימוש בו לאחסון סיסמאות ואסימונים אינו כל כך מפחיד. במהלך כל הניסויים שלי, מעולם לא הצלחתי לראות את הסוד בצורתו הטהורה בקונסולה.
• חינם עבור פרויקטים בקוד פתוח

חסרונות:

• YML, ובכן, אני לא אוהב אותו. כשעובדים עם זרימה כזו, הודעת ה-commit הנפוצה ביותר שיש לי היא "תקן yml פורמט", ואז אתה שוכח לשים טאב איפשהו, או שאתה כותב אותו בשורה הלא נכונה. בכלל, ישיבה מול מסך עם מד זווית וסרגל זו לא החוויה הכי נעימה.
• DEBUG, איתור באגים של הזרימה עם commits, הפעלת בנייה מחדש ופלט לקונסולה זה לא תמיד נוח, אבל זה יותר מקטגוריית "הגזמתם"; אתה רגיל לעבוד עם IDEA נוח, כאשר אתה יכול לנפות כל דבר .
• אתה יכול לכתוב את הפעולה שלך על כל דבר אם אתה עוטף אותה ב-Docker, אבל רק javascript נתמך באופן מקורי, כמובן שזה עניין של טעם, אבל אני מעדיף משהו אחר במקום js.

הרשו לי להזכיר לכם שהמאגר עם כל הסקריפטים נמצא כאן: github.com/antkorwin/github-actions

בשבוע הבא אני מופיע עם להגיש תלונה בכנס Heisenbug 2020 Piter. אני אגיד לך לא רק איך להימנע מטעויות בעת הכנת נתוני בדיקה, אלא גם לשתף את סודות העבודה שלי עם ערכות נתונים ביישומי Java!

מקור: www.habr.com