Ik moet vaak een pijplijn bouwen voor het bouwen van projecten in Java. Soms is het open source, soms niet. Ik heb onlangs besloten om een aantal van mijn repository's van Travis-CI en TeamCity naar GitHub Actions te verplaatsen, en dit is wat er uit voortkwam.
Wat gaan we automatiseren?
Eerst hebben we een project nodig dat we gaan automatiseren, laten we een kleine applicatie maken in Spring boot / Java 11 / Maven. Voor de doeleinden van dit artikel zullen we helemaal niet geïnteresseerd zijn in de applicatielogica; de infrastructuur rond de applicatie is belangrijk voor ons, dus een eenvoudige REST API-controller zal voor ons voldoende zijn.
De bronnen kun je hier bekijken: Alle fasen van het bouwen van een pijplijn worden weerspiegeld in de pull-aanvragen voor dit project.
JIRA en planning
Het is de moeite waard om te zeggen dat we JIRA meestal gebruiken als issue-tracker, dus laten we een apart bord maken voor dit project en daar de eerste problemen toevoegen:
Even later komen we terug op welke interessante dingen JIRA en GitHub in combinatie kunnen bieden.
Wij automatiseren de montage van het project
Ons testproject is gebouwd via maven, dus het bouwen ervan is vrij eenvoudig, het enige dat we nodig hebben is het mvn clean-pakket.
Om dit te doen met behulp van Github Actions, zullen we een bestand in de repository moeten maken dat onze workflow beschrijft. Dit kan gedaan worden met een gewoon yml-bestand. Ik kan niet zeggen dat ik van “yml-programmeren” hou, maar wat kunnen we doen - we doen het in de .github/ directory workflow/file build.yml waarin we de acties zullen beschrijven bij het bouwen van de master branch:
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 — dit is een beschrijving van het evenement waarop ons script wordt gelanceerd.
op: pull_request/push — geeft aan dat deze workflow moet worden gestart telkens wanneer er een push naar de master wordt gedaan en er pull-aanvragen worden gemaakt.
Hieronder volgt een beschrijving van de taken (vacatures) en uitvoeringsstappen (stappen) voor elke taak.
draait op - hier kunnen we het doelbesturingssysteem selecteren, verrassend genoeg kun je zelfs Mac OS kiezen, maar op privérepository's is dit behoorlijk duur (vergeleken met Linux).
toepassingen stelt u in staat andere acties opnieuw te gebruiken, bijvoorbeeld met behulp van de action/setup-java-actie installeren we de omgeving voor Java 11.
Door middel van Met we kunnen de parameters specificeren waarmee we de actie starten, in wezen zijn dit de argumenten die aan de actie worden doorgegeven.
Het enige dat overblijft is het uitvoeren van het project gebouwd in Maven: run: mvn -B clean package vlag -B zegt dat we een niet-interactieve modus nodig hebben, zodat de meester ons plotseling niets wil vragen
Geweldig! Elke keer dat u zich aan de master committeert, begint het bouwen van het project.
Testlanceringen automatiseren
Montage is goed, maar in werkelijkheid kan een project veilig worden gemonteerd, maar niet werken. Daarom is de volgende stap het automatiseren van de testruns. Bovendien is het best handig om naar de resultaten van het slagen voor de tests te kijken wanneer u een PR-beoordeling doet - u weet zeker dat de tests slagen en niemand vergat zijn branch uit te voeren voordat hij een merge deed.
We zullen tests uitvoeren bij het maken van een pull-aanvraag en deze samenvoegen met de master, en tegelijkertijd zullen we de creatie van een rapport over codedekking toevoegen.
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 }}
Voor tests gebruik ik codecov in combinatie met de jacoco-plug-in. codecov heeft zijn eigen actie, maar heeft een token nodig om met ons pull-verzoek te werken:
${{ secrets.CODECOV_TOKEN }} — we zullen deze constructie meer dan eens zien, geheimen zijn een mechanisme voor het opslaan van geheimen in GitHub, we kunnen daar wachtwoorden/tokens/hosts/urls en andere gegevens schrijven die niet in de codebasis van de repository mogen worden opgenomen.
Je kunt een variabele toevoegen aan geheimen in de repository-instellingen op GitHub:
Een token kun je krijgen bij Na autorisatie via GitHub hoeft u alleen maar een link als deze te volgen om een openbaar project toe te voegen: /[reponaam]. Er kan ook een privérepository worden toegevoegd; hiervoor moet u codecov-rechten aan de applicatie in Github geven.
Voeg de jacoco-plug-in toe aan het POM-bestand:
<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>
Nu zal de codecov-bot elk van onze pull-verzoeken invoeren en een dekkingswijzigingsgrafiek toevoegen:
Laten we een statische analysator toevoegen
In de meeste van mijn open source-projecten gebruik ik sonarcloud voor statische code-analyse. Het is vrij eenvoudig om verbinding te maken met travis-ci. Het is dus een logische stap bij het migreren naar GitHub Actions om hetzelfde te doen. De actiemarkt is een cool ding, maar deze keer liet het me een beetje in de steek, omdat ik uit gewoonte de actie vond die ik nodig had en deze aan de workflow toevoegde. Maar het bleek dat sonar geen ondersteuning biedt voor het doorlopen van een actie voor het analyseren van projecten op maven of gradle. Natuurlijk staat dit in de documentatie, maar wie leest het?!
Het is niet mogelijk via een actie, dus we doen het via de mvn-plug-in:
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 - verkrijgbaar bij en je moet het in het geheim registreren. GITHUB_TOKEN - dit is een ingebouwd token dat GitHub genereert, met behulp waarvan sonarcloud[bot] in staat zal zijn om in te loggen op Git om ons berichten achter te laten in pull-aanvragen.
Dsonar.projectKey — de naam van het project in de sonar, u kunt deze zien in de projectinstellingen.
Dsonar.organisatie — naam van de organisatie uit GitHub.
We doen een pull-verzoek en wachten tot sonarcloud[bot] in de reacties verschijnt:
Release management
De build is geconfigureerd, de tests zijn uitgevoerd en we kunnen een release maken. Laten we eens kijken hoe GitHub Actions releasebeheer veel eenvoudiger kan maken.
Op het werk heb ik projecten waarvan de codebasis in bitbucket ligt (alles is zoals in dat verhaal: "Ik schrijf overdag naar bitbucket, commit 's nachts aan GitHub"). Helaas heeft bitbucket geen ingebouwde tools voor releasebeheer. Dit is een probleem, omdat je voor elke release handmatig een samenvloeiende pagina moet maken en alle functies van de release daar naartoe moet gooien, door de paleizen van de geest moet zoeken, taken in Jira, commits in de repository. Er zijn veel kansen om een fout te maken, je kunt iets vergeten of iets invoeren dat de vorige keer al is uitgebracht, soms is het gewoon niet duidelijk hoe je een pull-verzoek moet classificeren: is het een functie of een bugfix, of het bewerken van tests, of iets infrastructureel.
Hoe kunnen GitHub-acties ons helpen? Er is een geweldige actie - release drafter, waarmee u een bestandssjabloon voor release-opmerkingen kunt instellen om categorieën van pull-aanvragen in te stellen en deze automatisch te groeperen in het bestand met release-opmerkingen:
Voorbeeldsjabloon voor het opzetten van een rapport (.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
Voeg een script toe om een conceptrelease te genereren (.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 }}
Alle pull-aanvragen worden vanaf nu automatisch verzameld in release-opmerkingen - magie!
Hier kan de vraag rijzen: wat als de ontwikkelaars vergeten tags in de PR te plaatsen? Dan is het niet duidelijk in welke categorie je het moet plaatsen, en opnieuw zul je het handmatig moeten afhandelen, bij elke PR afzonderlijk. Om dit probleem op te lossen, kunnen we een andere actie gebruiken: labelverifier. Deze controleert op de aanwezigheid van tags op het pull-verzoek. Als er geen vereiste tags zijn, mislukt de controle en zien we hierover een bericht in onze pull-request.
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'
Nu moet elke pull-request worden gemarkeerd met een van de tags: type:fix, type:features, type:documentation, type:tests, type:config.
Automatische annotatie van pull-aanvragen
Omdat we zo'n onderwerp als effectief werken met pull-aanvragen hebben besproken, is het de moeite waard om over een dergelijke actie als labeler te praten, het plaatst tags in PR op basis van welke bestanden zijn gewijzigd. We kunnen bijvoorbeeld elk pull-verzoek dat wijzigingen in de directory bevat, markeren als [build]. .github/workflow.
Het aansluiten is vrij eenvoudig:
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 }}
We hebben ook een bestand nodig dat de correspondentie beschrijft tussen de projectmappen en de pull-request-onderwerpen:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Het is mij niet gelukt om de actie die automatisch labels in pull-aanvragen plaatst te koppelen aan de actie die controleert op de aanwezigheid van vereiste labels; match-label wil niet dat de labels door de bot worden toegevoegd. Het lijkt gemakkelijker om je eigen actie te schrijven die beide fasen combineert. Maar zelfs in deze vorm is het best handig om te gebruiken: je moet een label uit de lijst selecteren wanneer je een pull-request maakt.
Het is tijd om in te zetten
Ik heb verschillende implementatieopties geprobeerd via GitHub Actions (via ssh, via scp en met behulp van docker-hub), en ik kan zeggen dat je hoogstwaarschijnlijk een manier zult vinden om het binaire bestand naar de server te uploaden, hoe krom je pijplijn ook is is.
Ik vond de optie om de hele infrastructuur op één plek te houden leuk, dus laten we eens kijken hoe we deze kunnen implementeren in GitHub-pakketten (dit is een opslagplaats voor binaire inhoud, npm, jar, docker).
Script voor het bouwen van een docker-image en het publiceren ervan in GitHub-pakketten:
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 }}"
Eerst moeten we het JAR-bestand van onze applicatie bouwen, waarna we het pad naar het GitHub docker-register en de naam van onze image berekenen. Er zijn hier een paar trucjes die we nog niet zijn tegengekomen:
- met een constructie als: echo “::set-output name=NAME::VALUE” kun je de waarde van een variabele in de huidige stap instellen, zodat deze vervolgens in alle andere stappen kan worden gelezen.
- je kunt de waarde van de variabele die in de vorige stap is ingesteld, verkrijgen via de ID van deze stap: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- De standaard GITHUB_REPOSITORY variabele slaat de naam van de repository en de eigenaar ervan (“eigenaar/repo-naam”) op. Om alles uit deze regel te verwijderen, behalve de naam van de repository, gebruiken we de bash-syntaxis: ${GITHUB_REPOSITORY#*/}
Vervolgens moeten we de docker-image bouwen:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Log in op het register:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
En publiceer de afbeelding naar GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Om de versie van de afbeelding aan te geven, gebruiken we de eerste cijfers van de SHA-hash van de commit - GITHUB_SHA, er zijn hier ook nuances, als je dergelijke builds niet alleen maakt bij het mergen in de master, maar ook volgens het maken van de pull-aanvraag event, dan komt SHA mogelijk niet overeen met de hash die we in de git-geschiedenis zien, omdat de action/checkout-actie zijn eigen unieke hash maakt om impasse-acties in de PR te voorkomen.
Als alles goed is gegaan, opent u de pakkettensectie (https://github.com/antkorwin/github-action/packages) in de repository en ziet u een nieuwe docker-afbeelding:
Daar kunt u ook een lijst met versies van de docker-image zien.
Het enige dat overblijft is het configureren van onze server om met dit register te werken en het opnieuw starten van de service. Ik zal waarschijnlijk een andere keer praten over hoe je dit via systemd kunt doen.
controle
Laten we eens kijken naar een eenvoudige optie voor het uitvoeren van een statuscheck voor onze applicatie met behulp van GitHub Actions. Onze opstartapplicatie heeft een actuator, dus we hoeven niet eens een API te schrijven om de status ervan te controleren; we hebben al alles gedaan voor de lui. Je hoeft alleen maar de host te trekken: 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"}
Het enige dat we nodig hebben, is een taak schrijven om de server te controleren met behulp van cron, en als deze ons plotseling niet antwoordt, sturen we een melding via telegram.
Laten we eerst eens kijken hoe we een cron-workflow kunnen uitvoeren:
on:
schedule:
- cron: '*/5 * * * *'
Het is simpel, ik kan niet eens geloven dat je in Github evenementen kunt maken die helemaal niet in webhooks passen. Details staan in de documentatie:
Laten we de serverstatus handmatig controleren via 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"
Eerst slaan we in een variabele op wat de server op het verzoek heeft gereageerd, in de volgende stap controleren we of de status UP is en als dit niet het geval is, sluiten we af met een foutmelding. Als je een actie met je handen moet ‘overweldigen’, dan verlaat 1 - geschikt wapen.
- 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 }}
We sturen alleen een telegram als de actie bij de vorige stap is mislukt. Om een bericht te sturen gebruiken we appleboy/telegram-action; hoe je een bottoken en chat-ID kunt krijgen, kun je lezen in de documentatie:
Vergeet niet de geheimen op Github in te voeren: URL voor de server en tokens voor de telegrambot.
Bonustrack - JIRA voor de lui
Ik heb beloofd dat we zouden terugkeren naar JIRA, en we zijn teruggekeerd. Honderden keren heb ik een situatie waargenomen bij stand-ups waarin ontwikkelaars een feature maakten, een branch samenvoegden, maar vergaten het probleem naar JIRA te slepen. Als dit allemaal op één plek zou gebeuren, zou het natuurlijk gemakkelijker zijn, maar in feite schrijven we code in de IDE, voegen we branches samen in bitbucket of GitHub en slepen we de taken vervolgens naar Jira, hiervoor moeten we nieuwe vensters openen , soms opnieuw inloggen en etc. Als je je perfect herinnert wat je vervolgens moet doen, heeft het geen zin om het bord opnieuw te openen. Als gevolg hiervan moet u 's ochtends tijdens een stand-up tijd besteden aan het bijwerken van het taakbord.
GitHub zal ons ook helpen bij deze routinetaak; om te beginnen kunnen we problemen automatisch naar de code_review-kolom slepen wanneer we een pull-verzoek indienen. Het enige wat u hoeft te doen is de naamgevingsconventie voor vertakkingen te volgen:
[имя проекта]-[номер таска]-название
Als de projectsleutel "GitHub Actions" bijvoorbeeld GA is, dan GA-8-jira-bot zou een tak kunnen zijn voor het implementeren van de GA-8-taak.
Integratie met JIRA werkt via acties van Atlassian, ze zijn niet perfect, ik moet zeggen dat sommige ervan helemaal niet voor mij werkten. Maar we zullen alleen degenen bespreken die zeker werken en actief worden gebruikt.
Eerst moet je inloggen bij JIRA met de actie: 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 }}
Om dit te doen heb je een token nodig in JIRA, hoe je dit doet staat hier beschreven:
We halen de taak-ID uit de filiaalnaam:
- 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}}
Als je op de GitHub-marktplaats zoekt, kun je een actie voor deze taak vinden, maar ik moest hetzelfde schrijven met grep en de naam van de branch gebruiken, omdat deze actie van Atlassian op geen enkele manier aan mijn project wilde werken , om erachter te komen wat daar mis was - langer dan hetzelfde met je handen doen.
Het enige dat overblijft is om de taak naar de kolom “Code review” te verplaatsen bij het maken van een pull-verzoek:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Er is hiervoor een speciale actie op GitHub, het enige dat hiervoor nodig is, is de issue-ID die we in de vorige stap hebben verkregen en de autorisatie in JIRA die we hierboven hebben gedaan.
Op dezelfde manier kun je taken slepen bij het samenvoegen in de master en andere gebeurtenissen vanuit de GitHub-workflow. Over het algemeen hangt het allemaal af van uw verbeeldingskracht en uw wens om routinematige processen te automatiseren.
Bevindingen
Als je naar het klassieke DEVOPS-diagram kijkt, hebben we alle fasen besproken, behalve misschien de bediening. Ik denk dat als je het probeert, je enige actie op de markt kunt vinden voor integratie met het helpdesksysteem, dus we gaan ervan uit dat de pijplijn is veranderd grondig zijn en er kunnen conclusies worden getrokken op basis van het gebruik ervan.
Voors:
- Marktplaats met kant-en-klare acties voor alle gelegenheden, dit is erg gaaf. In de meeste daarvan kun je ook naar de broncode kijken om te begrijpen hoe je een soortgelijk probleem kunt oplossen of een functieverzoek rechtstreeks bij de auteur in de GitHub-repository kunt plaatsen.
- Het selecteren van het doelplatform voor montage: Linux, mac os, windows is een behoorlijk interessante functie.
- Github Packages is een geweldig ding, het is handig om de hele infrastructuur op één plek te houden, je hoeft niet door verschillende vensters te surfen, alles bevindt zich binnen een straal van één of twee muisklikken en is perfect geïntegreerd met GitHub Actions. Docker-registerondersteuning in de gratis versie is ook een goed voordeel.
- GitHub verbergt geheimen in buildlogboeken, dus het is niet zo eng om het te gebruiken om wachtwoorden en tokens op te slaan. Tijdens al mijn experimenten heb ik het geheim nooit in zijn pure vorm in de console kunnen zien.
- Gratis voor Open Source-projecten
Tegens:
- YML, nou, ik vind hem niet leuk. Als ik met zo'n flow werk, is het meest voorkomende commit-bericht dat ik heb "fix yml format", dan vergeet je ergens een tabblad te plaatsen, of je schrijft het op de verkeerde regel. Over het algemeen is het niet de meest prettige ervaring om met een gradenboog en een liniaal voor een scherm te zitten.
- DEBUG, het debuggen van de stroom met commits, het opnieuw opbouwen en uitvoeren naar de console is niet altijd handig, maar het valt meer in de categorie "je bent overdreven"; je bent gewend om met handig IDEA te werken, wanneer je alles kunt debuggen .
- Je kunt je actie overal op schrijven als je het in Docker verpakt, maar alleen javascript wordt native ondersteund. Dit is natuurlijk een kwestie van smaak, maar ik zou liever iets anders hebben dan js.
Laat me je eraan herinneren dat de repository met alle scripts hier is:
Volgende week ga ik optreden met op de Piter-conferentie Heisenbug 2020. Ik zal je niet alleen vertellen hoe je fouten kunt voorkomen bij het voorbereiden van testgegevens, maar ook mijn geheimen delen over het werken met datasets in Java-applicaties!
Bron: www.habr.com