Generator Bitbucket Pipelines

Generuj konfigurację bitbucket-pipelines.yml: budowanie, testy, deployment. Szablony dla Node.js, PHP, Docker, AWS. Bezpłatnie.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Ustawienia

Typ projektu

Obraz Docker

Instalacja zależności

Testy

Budowanie

Użyj pamięci podręcznej (cache) Opcja narzędzia

Dodaj pipeline dla pull requestów Opcja narzędzia

Dodaj krok wdrożenia Opcja narzędzia

Gałąź wdrożenia

Polecenia wdrożenia

Wynik

image: 'node:20'

pipelines:
  default:
    - step:
        name: "Install & Test"
        caches:
          - node
        script:
          - npm ci
          - npm test
    - step:
        name: "Build"
        caches:
          - node
        script:
          - npm run build

  pull-requests:
    '**':
      - step:
          name: "PR Checks"
          caches:
            - node
          script:
            - npm ci
            - npm test

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator Bitbucket Pipelines – YAML CI/CD dla projektów Atlassian

Bitbucket Pipelines to wbudowany system CI/CD Bitbucket (Atlassian). Konfiguracja w pliku bitbucket-pipelines.yml w root repozytorium. Generator tworzy gotowe szablony dla popularnych stacków: Node.js, PHP, Python, Docker, z deploymentem na AWS/Heroku/własny serwer.

Bitbucket Pipelines CI/CD Bitbucket bitbucket-pipelines.yml generator pipeline CI

Podstawy Bitbucket Pipelines

Plik: bitbucket-pipelines.yml w root repo. Struktura: image (Docker), pipelines → branches/tags/pull-requests/custom. Step: name, script (komendy). Każdy step uruchamia się w kontenerze Docker. Artefakty: artifacts (przekazuj pliki między stepami). Cache: dependencies (npm, composer, pip).

Przykład pipeline Node.js

image: node:18. pipelines: branches: main: - step: name: Test and Build. script: - npm ci - npm test - npm run build. artifacts: - dist/**. - step: name: Deploy. deployment: production. script: - pipe: atlassian/aws-s3-deploy:1.4.0.

Zmienne środowiskowe

Repozytorium: Settings → Pipelines → Repository Variables. Encrypted: check "Secured" – masked w logach. Dostęp: $VARIABLE_NAME w skrypcie. Deployment variables: per deployment environment (staging/production). BITBUCKET_BRANCH: aktualna gałąź. BITBUCKET_COMMIT: hash commitu. BITBUCKET_BUILD_NUMBER.

Pipes – gotowe akcje

Pipes: prekonfigurowane integracje. atlassian/aws-s3-deploy: deploy na S3. atlassian/heroku-deploy. atlassian/ssh-run: run commands via SSH. atlassian/docker-push: push do registry. atlassian/git-secrets-scan: skan secretów. Marketplace: bitbucket.org/product/features/pipelines/integrations.

Jak działa generator bitbucket-pipelines.yml

Generator jest konwerterem formularza na tekst YAML. Ustawiasz wartości w polach: obraz bazowy, gałęzie i tagi wyzwalające pipeline, liczbę i zawartość kroków, ścieżki artefaktów oraz klucze cache. Każde pole odpowiada jednemu kluczowi w schemacie bitbucket-pipelines.yml, a generator składa je w jeden dokument, pilnując wcięć – w YAML wcięcie jest składnią, a nie kosmetyką.

Działanie jest deterministyczne: ten sam zestaw opcji daje identyczny plik. Kolejność bloków wynika ze schematu – najpierw ustawienia globalne, czyli image i definicje, potem pipelines z sekcjami branches, tags, pull-requests i custom, a wewnątrz nich stepy z kluczami name, script, artifacts, caches i deployment. Opcje ogólne są zapisywane raz, a nadpisania tylko tam, gdzie je wskażesz.

Wynikiem jest wyłącznie tekst pliku do skopiowania. Generator nie łączy się z repozytorium Bitbucket, nie uruchamia pipeline'u i nie sprawdza, czy komendy z script istnieją w wybranym obrazie. To warstwa konfiguracji – poprawność wykonania weryfikuje pierwszy przebieg na runnerze Bitbucket Cloud.

Przykład krok po kroku: projekt PHP z testami i deployem na własny serwer

W polu obrazu bazowego wybierz php i tag zgodny z wersją z pliku composer.json. Jeśli testy wymagają bazy danych, dodaj usługę w sekcji services i przekaż dane połączenia jako zmienne.
Zaznacz wyzwalacze: gałęzie main i develop oraz pull-requests. Sekcja pull-requests sprawi, że pipeline ruszy przy każdym pull requeście, jeszcze przed scaleniem zmian.
Zbuduj pierwszy krok o nazwie Test. W script wpisz instalację zależności przez composer, potem uruchomienie phpunit. W kluczu caches wskaż vendor powiązany z plikiem composer.lock, żeby kolejne przebiegi nie pobierały paczek od zera.
Dodaj drugi krok o nazwie Deploy i ustaw deployment na production. W script wywołaj pipe do zdalnych komend po SSH albo własne rsync. Adres hosta i klucz wstaw jako odwołania do zmiennych repozytorium, nigdy jako wartość jawną.
Wygeneruj YAML i zapisz go jako bitbucket-pipelines.yml w katalogu głównym repozytorium, na gałęzi, która ma wyzwalać pipeline.
Po pierwszym przebiegu przejrzyj logi obu kroków, popraw ścieżki artefaktów i klucz cache, jeśli zależności pobierają się ponownie. Dopiero wtedy konfiguracja jest kompletna.

Mapowanie opcji generatora na klucze YAML

Opcja w generatorze	Klucz w YAML	Uwagi
Obraz bazowy	image	Wspólny dla wszystkich kroków, o ile pojedynczy step nie nadpisuje go własnym obrazem.
Wyzwalacz gałęzi	pipelines.branches	Kluczem jest nazwa gałęzi, wartością lista kroków wykonywanych po jej wypchnięciu.
Wyzwalacz tagów	pipelines.tags	Działa na wzorcach tagów, przydaje się do wydań oznaczanych wersją.
Pull requesty	pipelines.pull-requests	Uruchamia pipeline przed scaleniem, można ograniczyć do wybranych gałęzi docelowych.
Krok	pipelines.*.step	Zawiera name i script; kroki wykonują się po kolei, każdy w świeżym kontenerze.
Artefakty	artifacts	Pliki przekazywane z kroku do kroku w obrębie jednego przebiegu, po nim znikają.
Cache	caches	Klucz i ścieżka katalogu, np. vendor lub node_modules; działa między przebiegami.
Uruchomienie ręczne	pipelines.custom	Pipeline startowany z interfejsu Bitbucket lub przez API, także dla wybranej gałęzi.

Praktyczne wskazówki przy generowaniu pipeline'u

Ustawiaj konkretny tag obrazu, nie latest – przypięta wersja chroni pipeline przed nagłą zmianą środowiska po aktualizacji obrazu w rejestrze.
Jeden krok, jedna odpowiedzialność – rozdzielenie testów, budowania i wdrożenia ułatwia cache'owanie, ponowne uruchomienie samego deployu i czytanie logów.
Nie myl cache z artefaktami – cache przyspiesza instalację zależności między przebiegami, artefakty przenoszą gotowe pliki z kroku do kroku. Wpisanie tego samego katalogu w oba miejsca zwykle nic nie daje.
Sekrety zostaw poza plikiem – generator wstawia tylko odwołania w stylu zmiennej, a wartości dodajesz w ustawieniach repozytorium i oznaczasz jako zabezpieczone, żeby nie trafiły do logów.
Testuj konfigurację na gałęzi roboczej – najpierw uruchom pipeline jako custom lub na gałęzi pomocniczej, a dopiero potem podłącz go do głównej gałęzi i środowiska produkcyjnego.

Czego generator nie uwzględnia

Nie zna struktury repozytorium – ścieżki do katalogów testów, katalogu wynikowego i cache trzeba dopasować ręcznie do układu projektu.
Nie sprawdza dostępności komend – generator dba o składnię YAML, ale nie zweryfikuje, czy wybrany obraz zawiera composer, phpunit, make czy klienta wybranej chmury.
Nie wstawia sekretów – tokeny, klucze SSH i hasła dodajesz poza generatorem, w konfiguracji repozytorium i środowisk wdrożeniowych.
Nie zna limitów konta ani runnerów – dostępny czas minutowy, rozmiar maszyny i możliwość użycia własnych runnerów zależą od planu Atlassian, a nie od wygenerowanego pliku.

Najczęstsze pytania

Jaka jest różnica między Bitbucket Pipelines a GitHub Actions?

Bitbucket: wbudowane w Bitbucket (Atlassian). YAML-based. Minuty: 50 darmowych/miesiąc (darmowy plan). GitHub Actions: event-triggered workflows. YAML. 2000 minut/miesiąc (darmowy). Marketplace: ogromny. GitLab CI: podobny do Bitbucket, .gitlab-ci.yml. Wspólne: Docker-based, konfiguracja YAML, integracje.

Jak przyspieszyć pipeline Bitbucket?

Caching: cache: key: dependencies. paths: node_modules/. Parallel steps: parallel: - step: name: Unit Tests. - step: name: Lint. Tylko na push do main: branches: main: ... Pull requests: dostają oddzielny pipeline. Docker image: użyj lekki image (alpine zamiast ubuntu). Skip pipeline: [skip ci] w commit message.

Jak deployować na własny serwer SSH?

Pipe: atlassian/ssh-run:0.4.1. Variables: SSH_USER, SERVER, SSH_KEY (Private key). Lub ręcznie: ssh-keyscan $SERVER >> ~/.ssh/known_hosts. scp build/* $SSH_USER@$SERVER:/var/www/. ssh $SSH_USER@$SERVER "cd /var/www && pm2 restart app". Klucz SSH: generuj ed25519, dodaj public do serwera, private do Bitbucket Variables.

Ile minut pipeline jest darmowych?

Free plan: 50 minut/miesiąc. Standard plan: 2500 minut/miesiąc. Premium: 3500 minut/miesiąc. Minuty liczą się od startu do końca step. Parallel steps: każdy liczy się osobno. Self-hosted runners: własny serwer = nielimitowane minuty (wymaga konfiguracji). Sprawdź zużycie: Settings → Pipelines → Minutes.

Jak testować pipeline lokalnie?

act (GitHub Actions): nie działa z Bitbucket. Simul8: bitbucket.org/simul8 (przestarzałe). Najlepiej: lokalny Docker. docker run -it node:18 bash → ręcznie wykonuj komendy z script. Walidacja YAML: yamllint lub online. Bitbucket: każdy push buduje pipeline (darmowe minuty zużywane). Tip: [skip ci] gdy testujesz.

Jak wygenerować plik bitbucket-pipelines.yml?

Ustaw w generatorze obraz bazowy, wyzwalacze i kroki, następnie skopiuj wynik i zapisz go jako bitbucket-pipelines.yml w katalogu głównym repozytorium. Nazwa i położenie pliku są sztywne, więc Bitbucket odczyta tylko tę ścieżkę.

Gdzie umieścić plik bitbucket-pipelines.yml w repozytorium?

W katalogu głównym repozytorium, na tej samej gałęzi co kod. Plik umieszczony w podkatalogu nie zostanie odczytany i pipeline się nie uruchomi.

Czy generator obsługuje pipeline dla pull requestów?

Tak, sekcja pull-requests jest jednym z czterech typów wyzwalaczy obok branches, tags i custom. Możesz ograniczyć ją do wybranych gałęzi docelowych, żeby nie uruchamiać pełnego pipeline'u przy każdym pull requeście.

Jak uruchomić pipeline ręcznie, bez wypychania commita?

Włącz sekcję custom – taki pipeline startuje z interfejsu Bitbucket albo przez API i może przyjmować parametry. Sprawdza się przy wdrożeniach oraz zadaniach serwisowych uruchamianych na żądanie.

Jak ograniczyć pipeline do zmian w wybranym katalogu?

Użyj warunku changesets z listą ścieżek w kroku – pipeline wykona się tylko wtedy, gdy zmiany dotyczą wskazanych plików. To przydatne w repozytoriach z kilkoma aplikacjami, gdzie nie każda zmiana wymaga pełnego przebiegu.

Powiązane narzedzia: generator GitHub Actions, generator Dockerfile i generator .gitignore.