GitHub ਐਕਸ਼ਨਾਂ ਨਾਲ ਨਰਕ ਦੇ ਚੱਕਰ (ਇੱਕ Java ਪ੍ਰੋਜੈਕਟ ਲਈ ਇੱਕ CI/CD ਪਾਈਪਲਾਈਨ ਬਣਾਉਣਾ)

ਮੈਨੂੰ ਅਕਸਰ Java ਵਿੱਚ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਲਈ ਇੱਕ ਪਾਈਪਲਾਈਨ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ। ਕਈ ਵਾਰ ਇਹ ਓਪਨ ਸੋਰਸ ਹੁੰਦਾ ਹੈ, ਕਈ ਵਾਰ ਇਹ ਨਹੀਂ ਹੁੰਦਾ। ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ ਆਪਣੀਆਂ ਕੁਝ ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਟ੍ਰੈਵਿਸ-ਸੀਆਈ ਅਤੇ ਟੀਮਸਿਟੀ ਤੋਂ ਗਿੱਟਹਬ ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਲਿਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਅਤੇ ਇਹ ਉਹੀ ਹੈ ਜੋ ਇਸ ਵਿੱਚੋਂ ਨਿਕਲਿਆ।

ਅਸੀਂ ਕੀ ਆਟੋਮੈਟਿਕ ਕਰਾਂਗੇ?

ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੀ ਲੋੜ ਹੈ ਜੋ ਅਸੀਂ ਆਟੋਮੇਟ ਕਰਾਂਗੇ, ਆਓ ਸਪਰਿੰਗ ਬੂਟ / ਜਾਵਾ 11 / ਮਾਵੇਨ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਐਪਲੀਕੇਸ਼ਨ ਕਰੀਏ. ਇਸ ਲੇਖ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ ਵਿੱਚ ਬਿਲਕੁਲ ਵੀ ਦਿਲਚਸਪੀ ਨਹੀਂ ਰੱਖਾਂਗੇ; ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਲੇ ਦੁਆਲੇ ਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਸਧਾਰਨ REST API ਕੰਟਰੋਲਰ ਸਾਡੇ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ।

ਤੁਸੀਂ ਇੱਥੇ ਸਰੋਤਾਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ: github.com/antkorwin/github-actions ਪਾਈਪਲਾਈਨ ਬਣਾਉਣ ਦੇ ਸਾਰੇ ਪੜਾਅ ਇਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਪੁੱਲ ਬੇਨਤੀਆਂ ਵਿੱਚ ਪ੍ਰਤੀਬਿੰਬਤ ਹੁੰਦੇ ਹਨ।

ਜੀਰਾ ਅਤੇ ਯੋਜਨਾਬੰਦੀ

ਇਹ ਕਹਿਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ JIRA ਨੂੰ ਇੱਕ ਮੁੱਦੇ ਟਰੈਕਰ ਵਜੋਂ ਵਰਤਦੇ ਹਾਂ, ਇਸਲਈ ਆਓ ਇਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਇੱਕ ਵੱਖਰਾ ਬੋਰਡ ਬਣਾਈਏ ਅਤੇ ਉੱਥੇ ਪਹਿਲੇ ਮੁੱਦੇ ਸ਼ਾਮਲ ਕਰੀਏ:

ਥੋੜੀ ਦੇਰ ਬਾਅਦ ਅਸੀਂ JIRA ਅਤੇ GitHub ਸੁਮੇਲ ਵਿੱਚ ਕਿਹੜੀਆਂ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦੇ ਹਾਂ 'ਤੇ ਵਾਪਸ ਆਵਾਂਗੇ।

ਅਸੀਂ ਪ੍ਰੋਜੈਕਟ ਦੀ ਅਸੈਂਬਲੀ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਦੇ ਹਾਂ

ਸਾਡਾ ਟੈਸਟ ਪ੍ਰੋਜੈਕਟ ਮੈਵੇਨ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਇਸਲਈ ਇਸਨੂੰ ਬਣਾਉਣਾ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ, ਸਾਨੂੰ ਸਿਰਫ਼ mvn ਸਾਫ਼ ਪੈਕੇਜ ਦੀ ਲੋੜ ਹੈ।

ਗੀਥਬ ਐਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਆਪਣੇ ਵਰਕਫਲੋ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਇਹ ਇੱਕ ਨਿਯਮਤ yml ਫਾਈਲ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਮੈਂ ਇਹ ਨਹੀਂ ਕਹਿ ਸਕਦਾ ਕਿ ਮੈਨੂੰ "yml ਪ੍ਰੋਗਰਾਮਿੰਗ" ਪਸੰਦ ਹੈ, ਪਰ ਅਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹਾਂ - ਅਸੀਂ ਇਸਨੂੰ .github/ ਡਾਇਰੈਕਟਰੀ ਵਰਕਫਲੋ/ ਫਾਈਲ 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 — ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਵਾਰ ਜਦੋਂ ਮਾਸਟਰ ਨੂੰ ਪੁਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੁੱਲ ਬੇਨਤੀਆਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਇਸ ਵਰਕਫਲੋ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੇ ਕੰਮਾਂ ਦਾ ਵੇਰਵਾ ਹੈ (ਨੌਕਰੀ) ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਟੈਪਸ (ਕਦਮ) ਹਰੇਕ ਕੰਮ ਲਈ।

ਚੱਲਦਾ ਹੈ - ਇੱਥੇ ਅਸੀਂ ਟਾਰਗੇਟ ਓਐਸ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹਾਂ, ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ ਕਿ ਤੁਸੀਂ ਮੈਕ ਓਐਸ ਵੀ ਚੁਣ ਸਕਦੇ ਹੋ, ਪਰ ਪ੍ਰਾਈਵੇਟ ਰਿਪੋਜ਼ਟਰੀਆਂ 'ਤੇ ਇਹ ਕਾਫ਼ੀ ਮਹਿੰਗਾ ਹੈ (ਲੀਨਕਸ ਦੇ ਮੁਕਾਬਲੇ)।

ਵਰਤਦਾ ਹੈ ਤੁਹਾਨੂੰ ਹੋਰ ਕਾਰਵਾਈਆਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਐਕਸ਼ਨ/ਸੈੱਟਅੱਪ-ਜਾਵਾ ਐਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਸੀਂ Java 11 ਲਈ ਵਾਤਾਵਰਣ ਨੂੰ ਸਥਾਪਤ ਕਰਦੇ ਹਾਂ।

ਦੀ ਸਹਾਇਤਾ ਨਾਲ ਨਾਲ ਅਸੀਂ ਉਹਨਾਂ ਮਾਪਦੰਡਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿਸ ਨਾਲ ਅਸੀਂ ਕਾਰਵਾਈ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇਹ ਉਹ ਆਰਗੂਮੈਂਟ ਹਨ ਜੋ ਕਾਰਵਾਈ ਨੂੰ ਪਾਸ ਕੀਤੇ ਜਾਣਗੇ।

ਮਾਵੇਨ ਦੇ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਬਿਲਡ ਨੂੰ ਚਲਾਉਣਾ ਬਾਕੀ ਹੈ: run: mvn -B clean package ਝੰਡਾ -B ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਾਨੂੰ ਇੱਕ ਗੈਰ-ਇੰਟਰਐਕਟਿਵ ਮੋਡ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਕਿ ਮਾਵੇਨ ਅਚਾਨਕ ਸਾਡੇ ਤੋਂ ਕੁਝ ਨਾ ਪੁੱਛਣਾ ਚਾਹੇ

ਬਹੁਤ ਵਧੀਆ! ਹੁਣ, ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਮਾਸਟਰ ਨੂੰ ਵਚਨਬੱਧ ਕਰਦੇ ਹੋ, ਪ੍ਰੋਜੈਕਟ ਬਿਲਡ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਆਟੋਮੇਟਿੰਗ ਟੈਸਟ ਲਾਂਚ ਕਰਦਾ ਹੈ

ਅਸੈਂਬਲੀ ਚੰਗੀ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ, ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਇਕੱਠਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਕੰਮ ਨਹੀਂ ਕਰਦਾ. ਇਸ ਲਈ, ਅਗਲਾ ਕਦਮ ਟੈਸਟ ਰਨ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਦੋਂ ਤੁਸੀਂ PR ਸਮੀਖਿਆ ਕਰਦੇ ਹੋ ਤਾਂ ਟੈਸਟਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਦੇਖਣਾ ਕਾਫ਼ੀ ਸੁਵਿਧਾਜਨਕ ਹੁੰਦਾ ਹੈ - ਤੁਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਜਾਣਦੇ ਹੋ ਕਿ ਟੈਸਟ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੋਈ ਵੀ ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਬ੍ਰਾਂਚ ਚਲਾਉਣਾ ਨਹੀਂ ਭੁੱਲਦਾ ਹੈ।

ਅਸੀਂ ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਉਣ ਵੇਲੇ ਟੈਸਟ ਚਲਾਵਾਂਗੇ ਅਤੇ ਮਾਸਟਰ ਵਿੱਚ ਅਭੇਦ ਹੋਵਾਂਗੇ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਅਸੀਂ ਕੋਡ-ਕਵਰੇਜ 'ਤੇ ਇੱਕ ਰਿਪੋਰਟ ਬਣਾਉਣ ਨੂੰ ਜੋੜਾਂਗੇ।

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

ਟੈਸਟਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ, ਮੈਂ ਜੈਕੋਕੋ ਪਲੱਗਇਨ ਦੇ ਨਾਲ ਕੋਡਕੋਵ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ। ਕੋਡਕੋਵ ਦੀ ਆਪਣੀ ਕਾਰਵਾਈ ਹੈ, ਪਰ ਇਸਨੂੰ ਸਾਡੀ ਪੁੱਲ ਬੇਨਤੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਟੋਕਨ ਦੀ ਲੋੜ ਹੈ:

${{ secrets.CODECOV_TOKEN }} — ਅਸੀਂ ਇਸ ਨਿਰਮਾਣ ਨੂੰ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਦੇਖਾਂਗੇ, ਭੇਦ GitHub ਵਿੱਚ ਭੇਦ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਹੈ, ਅਸੀਂ ਉੱਥੇ ਪਾਸਵਰਡ/ਟੋਕਨ/ਹੋਸਟ/urls ਅਤੇ ਹੋਰ ਡੇਟਾ ਲਿਖ ਸਕਦੇ ਹਾਂ ਜੋ ਰਿਪੋਜ਼ਟਰੀ ਕੋਡ ਬੇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

ਤੁਸੀਂ GitHub 'ਤੇ ਰਿਪੋਜ਼ਟਰੀ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਭੇਦ ਵਿੱਚ ਇੱਕ ਵੇਰੀਏਬਲ ਜੋੜ ਸਕਦੇ ਹੋ:

'ਤੇ ਟੋਕਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ codecov.io GitHub ਦੁਆਰਾ ਅਧਿਕਾਰਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਜਨਤਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਜੋੜਨ ਲਈ ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਇੱਕ ਲਿੰਕ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: GitHub ਉਪਭੋਗਤਾ ਨਾਮ/[ਰੇਪੋ ਨਾਮ]। ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਰਿਪੋਜ਼ਟਰੀ ਵੀ ਜੋੜੀ ਜਾ ਸਕਦੀ ਹੈ; ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ Github ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੋਡਕੋਵ ਅਧਿਕਾਰ ਦੇਣ ਦੀ ਲੋੜ ਹੈ।

ਜੈਕੋਕੋ ਪਲੱਗਇਨ ਨੂੰ 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>

ਹੁਣ ਕੋਡਕੋਵ ਬੋਟ ਸਾਡੀ ਹਰੇਕ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਦਾਖਲ ਕਰੇਗਾ ਅਤੇ ਇੱਕ ਕਵਰੇਜ ਤਬਦੀਲੀ ਗ੍ਰਾਫ ਸ਼ਾਮਲ ਕਰੇਗਾ:

ਆਉ ਇੱਕ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕ ਜੋੜੀਏ

ਮੇਰੇ ਜ਼ਿਆਦਾਤਰ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਮੈਂ ਸਟੈਟਿਕ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਸੋਨਾਰ ਕਲਾਉਡ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ, ਟ੍ਰੈਵਿਸ-ਸੀਆਈ ਨਾਲ ਜੁੜਨਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ. ਇਸ ਲਈ ਇਹ ਇੱਕ ਤਰਕਪੂਰਨ ਕਦਮ ਹੈ ਜਦੋਂ ਅਜਿਹਾ ਕਰਨ ਲਈ GitHub ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਐਕਸ਼ਨ ਮਾਰਕੀਟ ਇੱਕ ਵਧੀਆ ਚੀਜ਼ ਹੈ, ਪਰ ਇਸ ਵਾਰ ਇਸਨੇ ਮੈਨੂੰ ਥੋੜਾ ਨਿਰਾਸ਼ ਕੀਤਾ, ਕਿਉਂਕਿ ਆਦਤ ਤੋਂ ਬਾਹਰ ਮੈਨੂੰ ਉਹ ਕਾਰਵਾਈ ਮਿਲੀ ਜਿਸਦੀ ਮੈਨੂੰ ਲੋੜ ਸੀ ਅਤੇ ਇਸਨੂੰ ਵਰਕਫਲੋ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ। ਪਰ ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਸੋਨਾਰ ਮਾਵੇਨ ਜਾਂ ਗ੍ਰੇਡਲ 'ਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਇੱਕ ਐਕਸ਼ਨ ਦੁਆਰਾ ਕੰਮ ਕਰਨ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਇਹ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਪਰ ਇਸਨੂੰ ਕੌਣ ਪੜ੍ਹਦਾ ਹੈ?!

ਇਹ ਇੱਕ ਕਾਰਵਾਈ ਦੁਆਰਾ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਇਸਨੂੰ 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 ਤਿਆਰ ਕਰਦਾ ਹੈ, ਜਿਸਦੀ ਮਦਦ ਨਾਲ ਸੋਨਾਰਕਲਾਉਡ [ਬੋਟ] ਸਾਨੂੰ ਪੁੱਲ ਬੇਨਤੀਆਂ ਵਿੱਚ ਸੁਨੇਹੇ ਛੱਡਣ ਲਈ ਗਿੱਟ ਵਿੱਚ ਲੌਗਇਨ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ।

Dsonar.projectKey - ਸੋਨਾਰ ਵਿੱਚ ਪ੍ਰੋਜੈਕਟ ਦਾ ਨਾਮ, ਤੁਸੀਂ ਇਸਨੂੰ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ।

Dsonar.organization - GitHub ਤੋਂ ਸੰਸਥਾ ਦਾ ਨਾਮ।

ਅਸੀਂ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੋਨਾਰਕਲਾਉਡ [ਬੋਟ] ਦੀਆਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਆਉਣ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਾਂ:

ਰੀਲਿਜ਼ ਮੈਨੇਜਮੈਂਟ

ਬਿਲਡ ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਟੈਸਟ ਚਲਾਏ ਗਏ ਹਨ, ਅਤੇ ਅਸੀਂ ਇੱਕ ਰੀਲੀਜ਼ ਕਰ ਸਕਦੇ ਹਾਂ। ਆਓ ਦੇਖੀਏ ਕਿ ਕਿਵੇਂ GitHub ਐਕਸ਼ਨ ਰੀਲੀਜ਼ ਪ੍ਰਬੰਧਨ ਨੂੰ ਬਹੁਤ ਸੌਖਾ ਬਣਾ ਸਕਦੇ ਹਨ।

ਕੰਮ 'ਤੇ, ਮੇਰੇ ਕੋਲ ਪ੍ਰੋਜੈਕਟ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਡ ਬੇਸ ਬਿੱਟਬਕੇਟ ਵਿੱਚ ਹੈ (ਸਭ ਕੁਝ ਉਸ ਕਹਾਣੀ ਦੀ ਤਰ੍ਹਾਂ ਹੈ "ਮੈਂ ਦਿਨ ਵੇਲੇ ਬਿੱਟਬਕੇਟ ਨੂੰ ਲਿਖਦਾ ਹਾਂ, ਰਾਤ ​​ਨੂੰ ਗਿੱਟਹੱਬ ਨੂੰ ਵਚਨਬੱਧ ਕਰਦਾ ਹਾਂ")। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਬਿੱਟਬਕੇਟ ਵਿੱਚ ਬਿਲਟ-ਇਨ ਰੀਲੀਜ਼ ਪ੍ਰਬੰਧਨ ਟੂਲ ਨਹੀਂ ਹਨ। ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਰੀਲੀਜ਼ ਲਈ ਤੁਹਾਨੂੰ ਹੱਥੀਂ ਸੰਗਮ ਵਿੱਚ ਇੱਕ ਪੰਨਾ ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਰੀਲੀਜ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉੱਥੇ ਸੁੱਟਣਾ ਹੁੰਦਾ ਹੈ, ਮਨ ਦੇ ਮਹਿਲ ਵਿੱਚ ਖੋਜ ਕਰਨਾ, ਜੀਰਾ ਵਿੱਚ ਕੰਮ, ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਕਮਿਟ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਗਲਤੀ ਕਰਨ ਦੇ ਬਹੁਤ ਸਾਰੇ ਮੌਕੇ ਹਨ, ਤੁਸੀਂ ਕੁਝ ਭੁੱਲ ਸਕਦੇ ਹੋ ਜਾਂ ਕੁਝ ਅਜਿਹਾ ਦਾਖਲ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਪਿਛਲੀ ਵਾਰ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਈ ਵਾਰ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਕੀ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨਾ ਹੈ - ਕੀ ਇਹ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜਾਂ ਇੱਕ ਬੱਗ ਫਿਕਸ, ਜਾਂ ਸੰਪਾਦਨ ਟੈਸਟ, ਜਾਂ ਕੁਝ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

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

ਹੁਣ ਤੋਂ ਸਾਰੀਆਂ ਪੁੱਲ ਬੇਨਤੀਆਂ ਆਪਣੇ ਆਪ ਰਿਲੀਜ਼ ਨੋਟਸ ਵਿੱਚ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ - ਜਾਦੂ!

ਇੱਥੇ ਸਵਾਲ ਉੱਠ ਸਕਦਾ ਹੈ: ਜੇ ਡਿਵੈਲਪਰ ਪੀਆਰ ਵਿੱਚ ਟੈਗ ਲਗਾਉਣਾ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਫਿਰ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇਸਨੂੰ ਕਿਸ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਰੱਖਣਾ ਹੈ, ਅਤੇ ਦੁਬਾਰਾ ਤੁਹਾਨੂੰ ਇਸ ਨਾਲ ਹੱਥੀਂ ਨਜਿੱਠਣਾ ਪਏਗਾ, ਹਰੇਕ ਪੀਆਰ ਨਾਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ. ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਹੋਰ ਕਾਰਵਾਈ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ - ਲੇਬਲ ਵੈਰੀਫਾਇਰ - ਇਹ ਪੁੱਲ ਬੇਨਤੀ 'ਤੇ ਟੈਗਸ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਲੋੜੀਂਦੇ ਟੈਗ ਨਹੀਂ ਹਨ, ਤਾਂ ਜਾਂਚ ਅਸਫਲ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਅਸੀਂ ਆਪਣੀ ਪੁੱਲ ਬੇਨਤੀ ਵਿੱਚ ਇਸ ਬਾਰੇ ਇੱਕ ਸੁਨੇਹਾ ਦੇਖਾਂਗੇ।

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 ਵਿੱਚ ਟੈਗ ਰੱਖਦਾ ਹੈ ਜਿਸ ਦੇ ਅਧਾਰ ਤੇ ਫਾਈਲਾਂ ਨੂੰ ਬਦਲਿਆ ਗਿਆ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਕਿਸੇ ਵੀ ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ [ਬਿਲਡ] ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਸ਼ਾਮਲ ਹਨ .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/**"

ਮੈਂ ਉਸ ਕਾਰਵਾਈ ਨੂੰ ਜੋੜਨ ਵਿੱਚ ਸਫਲ ਨਹੀਂ ਹੋਇਆ ਜੋ ਲੋੜੀਂਦੇ ਲੇਬਲਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੀ ਕਾਰਵਾਈ ਦੇ ਨਾਲ ਪੁੱਲ ਬੇਨਤੀਆਂ ਵਿੱਚ ਲੇਬਲਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਰੱਖਦਾ ਹੈ; ਮੈਚ-ਲੇਬਲ ਬੋਟ ਦੁਆਰਾ ਸ਼ਾਮਲ ਕੀਤੇ ਲੇਬਲਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਆਪਣੀ ਕਾਰਵਾਈ ਲਿਖਣਾ ਸੌਖਾ ਲੱਗਦਾ ਹੈ ਜੋ ਦੋਵਾਂ ਪੜਾਵਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਪਰ ਇਸ ਫਾਰਮ ਵਿੱਚ ਵੀ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਸੁਵਿਧਾਜਨਕ ਹੈ; ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਉਣ ਵੇਲੇ ਤੁਹਾਨੂੰ ਸੂਚੀ ਵਿੱਚੋਂ ਇੱਕ ਲੇਬਲ ਚੁਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਹ ਤੈਨਾਤ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ

ਮੈਂ ਗਿਟਹਬ ਐਕਸ਼ਨਜ਼ (ssh ਦੁਆਰਾ, scp ਦੁਆਰਾ, ਅਤੇ docker-hub ਦੀ ਵਰਤੋਂ ਕਰਕੇ) ਦੁਆਰਾ ਕਈ ਤੈਨਾਤੀ ਵਿਕਲਪਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਅਤੇ ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ, ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਤੁਹਾਨੂੰ ਸਰਵਰ ਤੇ ਬਾਈਨਰੀ ਅਪਲੋਡ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਮਿਲੇਗਾ, ਭਾਵੇਂ ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ ਕਿੰਨੀ ਵੀ ਟੇਢੀ ਕਿਉਂ ਨਾ ਹੋਵੇ। ਹੈ.

ਮੈਨੂੰ ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖਣ ਦਾ ਵਿਕਲਪ ਪਸੰਦ ਹੈ, ਇਸ ਲਈ ਆਓ ਦੇਖੀਏ ਕਿ GitHub ਪੈਕੇਜਾਂ ਨੂੰ ਕਿਵੇਂ ਤੈਨਾਤ ਕਰਨਾ ਹੈ (ਇਹ ਬਾਈਨਰੀ ਸਮੱਗਰੀ, npm, jar, 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 ਡੌਕਰ ਰਜਿਸਟਰੀ ਦੇ ਮਾਰਗ ਅਤੇ ਸਾਡੇ ਚਿੱਤਰ ਦੇ ਨਾਮ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ। ਇੱਥੇ ਕੁਝ ਗੁਰੁਰ ਹਨ ਜੋ ਅਸੀਂ ਅਜੇ ਤੱਕ ਨਹੀਂ ਆਏ ਹਨ:

• ਇੱਕ ਉਸਾਰੀ ਜਿਵੇਂ ਕਿ: echo “::set-output name=NAME::VALUE” ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਪੜਾਅ ਵਿੱਚ ਇੱਕ ਵੇਰੀਏਬਲ ਦਾ ਮੁੱਲ ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਇਸਨੂੰ ਫਿਰ ਹੋਰ ਸਾਰੇ ਪੜਾਵਾਂ ਵਿੱਚ ਪੜ੍ਹਿਆ ਜਾ ਸਕੇ।
• ਤੁਸੀਂ ਇਸ ਪਗ ਦੇ ਪਛਾਣਕਰਤਾ ਦੁਆਰਾ ਪਿਛਲੇ ਪੜਾਅ ਵਿੱਚ ਸੈੱਟ ਕੀਤੇ ਵੇਰੀਏਬਲ ਦਾ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• ਮਿਆਰੀ GITHUB_REPOSITORY ਵੇਰੀਏਬਲ ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਨਾਮ ਅਤੇ ਇਸਦੇ ਮਾਲਕ ("ਮਾਲਕ/ਰੈਪੋ-ਨਾਮ") ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਨਾਮ ਨੂੰ ਛੱਡ ਕੇ ਇਸ ਲਾਈਨ ਤੋਂ ਸਭ ਕੁਝ ਕੱਟਣ ਲਈ, ਅਸੀਂ ਬੈਸ਼ ਸੰਟੈਕਸ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ: ${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 ਹੈਸ਼ ਤੋਂ ਪਹਿਲੇ ਅੰਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ - GITHUB_SHA ਇੱਥੇ ਵੀ ਸੂਖਮਤਾਵਾਂ ਹਨ, ਜੇਕਰ ਤੁਸੀਂ ਅਜਿਹੇ ਬਿਲਡਾਂ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਮਾਸਟਰ ਵਿੱਚ ਅਭੇਦ ਹੋਣ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਬਲਕਿ ਪੁੱਲ ਬੇਨਤੀ ਰਚਨਾ ਦੇ ਅਨੁਸਾਰ ਵੀ ਬਣਾਉਂਦੇ ਹੋ. ਈਵੈਂਟ, ਤਾਂ SHA ਉਸ ਹੈਸ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਜੋ ਅਸੀਂ ਗਿੱਟ ਇਤਿਹਾਸ ਵਿੱਚ ਵੇਖਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਐਕਸ਼ਨ/ਚੈੱਕਆਉਟ ਐਕਸ਼ਨ PR ਵਿੱਚ ਡੈੱਡਲਾਕ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਤੋਂ ਬਚਣ ਲਈ ਆਪਣੀ ਵਿਲੱਖਣ ਹੈਸ਼ ਬਣਾਉਂਦੀ ਹੈ।

ਜੇ ਸਭ ਕੁਝ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਪੈਕੇਜ ਭਾਗ (https://github.com/antkorwin/github-actions/packages) ਖੋਲ੍ਹਣ ਨਾਲ, ਤੁਸੀਂ ਇੱਕ ਨਵੀਂ ਡੌਕਰ ਚਿੱਤਰ ਵੇਖੋਗੇ:

ਉੱਥੇ ਤੁਸੀਂ ਡੌਕਰ ਚਿੱਤਰ ਦੇ ਸੰਸਕਰਣਾਂ ਦੀ ਸੂਚੀ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ.

ਇਸ ਰਜਿਸਟਰੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸਾਡੇ ਸਰਵਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਅਤੇ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਬਾਕੀ ਹੈ। ਮੈਂ ਸ਼ਾਇਦ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ ਕਿ ਇਹ ਕਿਸੇ ਹੋਰ ਸਮੇਂ ਸਿਸਟਮਡ ਦੁਆਰਾ ਕਿਵੇਂ ਕਰਨਾ ਹੈ.

ਨਿਗਰਾਨੀ

GitHub ਐਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸਿਹਤ ਜਾਂਚ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਇਸ ਬਾਰੇ ਇੱਕ ਸਧਾਰਨ ਵਿਕਲਪ ਨੂੰ ਵੇਖੀਏ। ਸਾਡੀ ਬੂਟ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਐਕਟੂਏਟਰ ਹੈ, ਇਸਲਈ ਸਾਨੂੰ ਇਸਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ 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"}

ਸਾਨੂੰ ਸਿਰਫ਼ ਕ੍ਰੋਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਰਵਰ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਕੰਮ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਜੇਕਰ ਅਚਾਨਕ ਇਹ ਸਾਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਟੈਲੀਗ੍ਰਾਮ ਰਾਹੀਂ ਇੱਕ ਸੂਚਨਾ ਭੇਜਾਂਗੇ।

ਪਹਿਲਾਂ, ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਕ੍ਰੋਨ ਵਰਕਫਲੋ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ:

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

ਇਹ ਸਧਾਰਨ ਹੈ, ਮੈਂ ਇਹ ਵੀ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਗਿਥਬ ਵਿੱਚ ਤੁਸੀਂ ਇਵੈਂਟਸ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਵੈਬਹੁੱਕ ਵਿੱਚ ਬਿਲਕੁਲ ਵੀ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ. ਵੇਰਵੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹਨ: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

ਆਉ ਕਰਲ ਦੁਆਰਾ ਸਰਵਰ ਸਥਿਤੀ ਦੀ ਖੁਦ ਜਾਂਚ ਕਰੀਏ:

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

ਅਸੀਂ ਸਿਰਫ ਤਾਂ ਹੀ ਟੈਲੀਗ੍ਰਾਮ 'ਤੇ ਭੇਜਦੇ ਹਾਂ ਜੇਕਰ ਪਿਛਲੇ ਪੜਾਅ 'ਤੇ ਕਾਰਵਾਈ ਅਸਫਲ ਹੋਈ। ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਣ ਲਈ ਅਸੀਂ ਐਪਲਬੌਏ/ਟੈਲੀਗ੍ਰਾਮ-ਐਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ; ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਬੋਟ ਟੋਕਨ ਅਤੇ ਚੈਟ ਆਈਡੀ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰੀਏ ਬਾਰੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ: github.com/appleboy/telegram-action

Github 'ਤੇ ਭੇਦ ਲਿਖਣਾ ਨਾ ਭੁੱਲੋ: ਸਰਵਰ ਲਈ URL ਅਤੇ ਟੈਲੀਗ੍ਰਾਮ ਬੋਟ ਲਈ ਟੋਕਨ।

ਬੋਨਸ ਟਰੈਕ - ਆਲਸੀ ਲਈ JIRA

ਮੈਂ ਵਾਅਦਾ ਕੀਤਾ ਸੀ ਕਿ ਅਸੀਂ ਜੀਰਾ ਵਾਪਸ ਆਵਾਂਗੇ, ਅਤੇ ਅਸੀਂ ਵਾਪਸ ਆ ਗਏ ਹਾਂ. ਸੈਂਕੜੇ ਵਾਰ ਮੈਂ ਸਟੈਂਡ-ਅਪ 'ਤੇ ਸਥਿਤੀ ਨੂੰ ਦੇਖਿਆ ਹੈ ਜਦੋਂ ਡਿਵੈਲਪਰਾਂ ਨੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਬਣਾਈ, ਇੱਕ ਸ਼ਾਖਾ ਨੂੰ ਮਿਲਾਇਆ, ਪਰ ਮੁੱਦੇ ਨੂੰ JIRA ਵਿੱਚ ਖਿੱਚਣਾ ਭੁੱਲ ਗਿਆ. ਬੇਸ਼ੱਕ, ਜੇਕਰ ਇਹ ਸਭ ਇੱਕ ਥਾਂ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ, ਤਾਂ ਇਹ ਸੌਖਾ ਹੁੰਦਾ, ਪਰ ਅਸਲ ਵਿੱਚ ਅਸੀਂ IDE ਵਿੱਚ ਕੋਡ ਲਿਖਦੇ ਹਾਂ, ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਬਿੱਟਬਕੇਟ ਜਾਂ ਗਿਟਹੱਬ ਵਿੱਚ ਮਿਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਫਿਰ ਕਾਰਜਾਂ ਨੂੰ ਜੀਰਾ ਵਿੱਚ ਖਿੱਚਦੇ ਹਾਂ, ਇਸਦੇ ਲਈ ਸਾਨੂੰ ਨਵੀਆਂ ਵਿੰਡੋਜ਼ ਖੋਲ੍ਹਣੀਆਂ ਪੈਣਗੀਆਂ। , ਕਈ ਵਾਰ ਦੁਬਾਰਾ ਲਾਗਇਨ ਕਰੋ ਅਤੇ ਆਦਿ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯਾਦ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਅੱਗੇ ਕੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਬੋਰਡ ਨੂੰ ਦੁਬਾਰਾ ਖੋਲ੍ਹਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਵੇਰੇ ਸਟੈਂਡਅੱਪ 'ਤੇ ਤੁਹਾਨੂੰ ਟਾਸਕ ਬੋਰਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਸਮਾਂ ਬਿਤਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

GitHub ਇਸ ਰੁਟੀਨ ਕੰਮ ਵਿੱਚ ਵੀ ਸਾਡੀ ਮਦਦ ਕਰੇਗਾ; ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲਿਆਂ ਲਈ, ਜਦੋਂ ਅਸੀਂ ਪੁੱਲ ਬੇਨਤੀ ਜਮ੍ਹਾਂ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਆਪਣੇ ਆਪ ਹੀ ਮੁੱਦਿਆਂ ਨੂੰ ਕੋਡ_ਰੀਵਿਊ ਕਾਲਮ ਵਿੱਚ ਖਿੱਚ ਸਕਦੇ ਹਾਂ। ਤੁਹਾਨੂੰ ਬਸ ਸ਼ਾਖਾ ਦੇ ਨਾਮਕਰਨ ਸੰਮੇਲਨ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

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

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਪ੍ਰੋਜੈਕਟ ਕੁੰਜੀ "GitHub ਐਕਸ਼ਨ" 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 'ਤੇ ਇਸਦੇ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਾਰਵਾਈ ਹੈ, ਇਸਦੀ ਲੋੜ ਸਿਰਫ਼ ਪਿਛਲੇ ਪੜਾਅ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਮੁੱਦਾ ID ਅਤੇ JIRA ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਹੈ ਜੋ ਅਸੀਂ ਉੱਪਰ ਕੀਤਾ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਤੁਸੀਂ ਮਾਸਟਰ ਵਿੱਚ ਅਭੇਦ ਹੋਣ ਵੇਲੇ ਕਾਰਜਾਂ ਨੂੰ ਖਿੱਚ ਸਕਦੇ ਹੋ, ਅਤੇ GitHub ਵਰਕਫਲੋ ਤੋਂ ਹੋਰ ਇਵੈਂਟਸ। ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਸਭ ਤੁਹਾਡੀ ਕਲਪਨਾ ਅਤੇ ਰੁਟੀਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਦੀ ਇੱਛਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.

ਸਿੱਟਾ

ਜੇ ਤੁਸੀਂ ਕਲਾਸਿਕ DEVOPS ਡਾਇਗ੍ਰਾਮ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਅਸੀਂ ਸਾਰੇ ਪੜਾਵਾਂ ਨੂੰ ਕਵਰ ਕੀਤਾ ਹੈ, ਸ਼ਾਇਦ ਸੰਚਾਲਨ ਨੂੰ ਛੱਡ ਕੇ, ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਹੈਲਪ-ਡੈਸਕ ਸਿਸਟਮ ਨਾਲ ਏਕੀਕਰਣ ਲਈ ਮਾਰਕੀਟ ਵਿੱਚ ਕੁਝ ਕਾਰਵਾਈ ਲੱਭ ਸਕਦੇ ਹੋ, ਇਸ ਲਈ ਅਸੀਂ ਇਹ ਮੰਨਾਂਗੇ ਕਿ ਪਾਈਪਲਾਈਨ ਬਦਲ ਗਈ ਇਸਦੀ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਤੇ ਸਿੱਟੇ ਕੱਢੇ ਜਾ ਸਕਦੇ ਹਨ।

ਪ੍ਰੋ:

• ਸਾਰੇ ਮੌਕਿਆਂ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਕਾਰਵਾਈਆਂ ਵਾਲਾ ਬਾਜ਼ਾਰ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਵਿੱਚ, ਤੁਸੀਂ ਇਹ ਸਮਝਣ ਲਈ ਸਰੋਤ ਕੋਡ ਨੂੰ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਸਮਾਨ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ ਜਾਂ GitHub ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਿੱਧੇ ਲੇਖਕ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਬੇਨਤੀ ਪੋਸਟ ਕਰ ਸਕਦੇ ਹੋ।
• ਅਸੈਂਬਲੀ ਲਈ ਟੀਚਾ ਪਲੇਟਫਾਰਮ ਦੀ ਚੋਣ ਕਰਨਾ: ਲੀਨਕਸ, ਮੈਕ ਓਐਸ, ਵਿੰਡੋਜ਼ ਕਾਫ਼ੀ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।
• ਗਿਥਬ ਪੈਕੇਜ ਇੱਕ ਵਧੀਆ ਚੀਜ਼ ਹੈ, ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖਣਾ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਵਿੰਡੋਜ਼ ਰਾਹੀਂ ਸਰਫ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਹਰ ਚੀਜ਼ ਇੱਕ ਜਾਂ ਦੋ ਮਾਊਸ ਕਲਿੱਕਾਂ ਦੇ ਘੇਰੇ ਵਿੱਚ ਹੈ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਗਿੱਟਹਬ ਐਕਸ਼ਨਜ਼ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੈ। ਮੁਫਤ ਸੰਸਕਰਣ ਵਿੱਚ ਡੌਕਰ ਰਜਿਸਟਰੀ ਸਹਾਇਤਾ ਵੀ ਇੱਕ ਚੰਗਾ ਫਾਇਦਾ ਹੈ।
• GitHub ਬਿਲਡ ਲੌਗਸ ਵਿੱਚ ਭੇਦ ਲੁਕਾਉਂਦਾ ਹੈ, ਇਸਲਈ ਪਾਸਵਰਡ ਅਤੇ ਟੋਕਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਇਸਦਾ ਉਪਯੋਗ ਕਰਨਾ ਇੰਨਾ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ। ਮੇਰੇ ਸਾਰੇ ਪ੍ਰਯੋਗਾਂ ਦੇ ਦੌਰਾਨ, ਮੈਂ ਕਦੇ ਵੀ ਕੰਸੋਲ ਵਿੱਚ ਇਸਦੇ ਸ਼ੁੱਧ ਰੂਪ ਵਿੱਚ ਰਾਜ਼ ਨੂੰ ਵੇਖਣ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ.
• ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਮੁਫ਼ਤ

ਨੁਕਸਾਨ:

• YML, ਠੀਕ ਹੈ, ਮੈਂ ਉਸਨੂੰ ਪਸੰਦ ਨਹੀਂ ਕਰਦਾ. ਅਜਿਹੇ ਪ੍ਰਵਾਹ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਮੇਰੇ ਕੋਲ ਸਭ ਤੋਂ ਆਮ ਪ੍ਰਤੀਬੱਧ ਸੰਦੇਸ਼ ਹੈ "ਫਿਕਸ yml ਫਾਰਮੈਟ", ਫਿਰ ਤੁਸੀਂ ਕਿਤੇ ਟੈਬ ਲਗਾਉਣਾ ਭੁੱਲ ਜਾਂਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਗਲਤ ਲਾਈਨ 'ਤੇ ਲਿਖਦੇ ਹੋ. ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਪ੍ਰੋਟੈਕਟਰ ਅਤੇ ਸ਼ਾਸਕ ਦੇ ਨਾਲ ਇੱਕ ਸਕ੍ਰੀਨ ਦੇ ਸਾਹਮਣੇ ਬੈਠਣਾ ਸਭ ਤੋਂ ਸੁਹਾਵਣਾ ਅਨੁਭਵ ਨਹੀਂ ਹੈ.
• ਡੀਬੱਗ, ਕਮਿਟ ਦੇ ਨਾਲ ਵਹਾਅ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ, ਰੀਬਿਲਡ ਚਲਾਉਣਾ, ਅਤੇ ਕੰਸੋਲ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨਾ ਹਮੇਸ਼ਾ ਸੁਵਿਧਾਜਨਕ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ "ਤੁਸੀਂ ਓਵਰਡੋਨ ਹੋ" ਸ਼੍ਰੇਣੀ ਤੋਂ ਵੱਧ ਹੈ; ਤੁਸੀਂ ਸੁਵਿਧਾਜਨਕ IDEA ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਆਦੀ ਹੋ, ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਵੀ ਡੀਬੱਗ ਕਰ ਸਕਦੇ ਹੋ .
• ਤੁਸੀਂ ਆਪਣੀ ਕਾਰਵਾਈ ਨੂੰ ਕਿਸੇ ਵੀ ਚੀਜ਼ 'ਤੇ ਲਿਖ ਸਕਦੇ ਹੋ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਡੌਕਰ ਵਿੱਚ ਲਪੇਟਦੇ ਹੋ, ਪਰ ਸਿਰਫ ਜਾਵਾਸਕ੍ਰਿਪਟ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰਥਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਬੇਸ਼ਕ ਇਹ ਸਵਾਦ ਦੀ ਗੱਲ ਹੈ, ਪਰ ਮੈਂ js ਦੀ ਬਜਾਏ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਤਰਜੀਹ ਦੇਵਾਂਗਾ.

ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਸਾਰੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਵਾਲਾ ਰਿਪੋਜ਼ਟਰੀ ਇੱਥੇ ਹੈ: github.com/antkorwin/github-actions

ਅਗਲੇ ਹਫਤੇ ਮੈਂ ਨਾਲ ਪਰਫਾਰਮ ਕਰਾਂਗਾ ਰਿਪੋਰਟ Heisenbug 2020 Piter ਕਾਨਫਰੰਸ ਵਿੱਚ। ਮੈਂ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਾਂਗਾ ਕਿ ਟੈਸਟ ਡੇਟਾ ਤਿਆਰ ਕਰਦੇ ਸਮੇਂ ਗਲਤੀਆਂ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ, ਬਲਕਿ Java ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਡੇਟਾ ਸੈੱਟਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਮੇਰੇ ਰਾਜ਼ ਵੀ ਸਾਂਝੇ ਕਰਾਂਗਾ!

ਸਰੋਤ: www.habr.com