Actions aufsetzen #38
@@ -11,28 +11,29 @@ jobs:
|
|||||||
- name: Checkout code
|
- name: Checkout code
|
||||||
uses: actions/checkout@v4
|
uses: actions/checkout@v4
|
||||||
|
|
||||||
- name: Install jq
|
- name: Install dependencies
|
||||||
run: |
|
run: |
|
||||||
apt-get update
|
apt-get update
|
||||||
apt-get install -y jq
|
apt-get install -y jq git wget unzip xz-utils
|
||||||
|
|
||||||
- name: Set Up Flutter
|
- name: Install Flutter (lokal)
|
||||||
uses: flutter-actions/setup-flutter@v2
|
|
||||||
with:
|
|
||||||
flutter-version: '3.35.6'
|
|
||||||
channel: 'stable'
|
|
||||||
|
|
||||||
- name: Configure Git Safe Directory
|
|
||||||
run: |
|
run: |
|
||||||
git config --global --add safe.directory /workspace/liquid-development/game-tracker
|
wget https://storage.googleapis.com/flutter_infra_release/releases/stable/linux/flutter_linux_3.38.2-stable.tar.xz
|
||||||
git config --global --add safe.directory /workspace/liquid-development/game-tracker/flutter
|
tar xf flutter_linux_3.38.2-stable.tar.xz
|
||||||
|
# Git-Safe-Directory für Flutter-Pfad setzen
|
||||||
|
git config --global --add safe.directory "$(pwd)/flutter"
|
||||||
|
# Flutter-Pfad setzen
|
||||||
|
echo "$(pwd)/flutter/bin" >> $GITHUB_PATH
|
||||||
|
|
||||||
|
- name: Configure Git Safe Directory (für Projekt)
|
||||||
|
run: |
|
||||||
|
|
|||||||
|
git config --global --add safe.directory "$(pwd)"
|
||||||
|
|
||||||
- name: Get dependencies
|
- name: Get dependencies
|
||||||
run: flutter pub get
|
run: ./flutter/bin/flutter pub get
|
||||||
|
|
||||||
- name: Check Formatting
|
- name: Check Formatting
|
||||||
run: flutter analyze
|
run: ./flutter/bin/flutter analyze
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user
kannst du das flutter install, get dependencies, apt-get und so nicht in einem workflow machen, sodass das nicht hier redundant ist?
Ne kann ich leider nicht, weil vor allem wenn die jobs parallel laufen (was sie jetzt gerade tun), auf zwei unterschiedlichen runnern laufen und nach jedem job wird der runner wieder in den ursprungszustand zurückgesetzt
Selbst wenn sie nicht parallel laufen würden, setzen sie sich bei jedem workflow immer wieder zurück