Removed unused files and not needed subdirs

This reverts commit 8396169b19.

README.md

@@ -1,353 +0,0 @@
-# user-microservice
-
-Mikroserwis REST do zarządzania kontami użytkowników, zbudowany w celu **porównania
-narzędzi CI/CD do automatycznego budowania i wdrażania aplikacji skonteneryzowanych**.
-Projekt powstał w ramach pracy magisterskiej.
-
-To repozytorium zawiera **kod aplikacji** oraz **potoki CI** (budowanie, testy, publikacja
-obrazu, aktualizacja repozytorium GitOps). Manifesty Kubernetes i konfiguracje narzędzi CD
-znajdują się w drugim repozytorium: **[`user-microservice-deploy`](../user-microservice-deploy)**.
-
----
-
-## Spis treści
-
-- [Cel projektu](#cel-projektu)
-- [Architektura rozwiązania](#architektura-rozwiązania)
-- [Porównywane narzędzia (5)](#porównywane-narzędzia-5)
-- [Scenariusze pomiarowe](#scenariusze-pomiarowe)
-- [Mapa branchy](#mapa-branchy)
-- [Aplikacja](#aplikacja)
-  - [Stos technologiczny](#stos-technologiczny)
-  - [API](#api)
-  - [Model danych](#model-danych)
-  - [Konfiguracja (zmienne środowiskowe)](#konfiguracja-zmienne-środowiskowe)
-  - [Uruchomienie lokalne](#uruchomienie-lokalne)
-  - [Testy](#testy)
-- [Potoki CI](#potoki-ci)
-  - [Jenkins](#jenkins)
-  - [Woodpecker CI](#woodpecker-ci)
-  - [Argo Workflows](#argo-workflows)
-  - [Wspólny schemat potoku CI](#wspólny-schemat-potoku-ci)
-- [Infrastruktura](#infrastruktura)
-- [Pomiar dostarczenia zmiany](#pomiar-dostarczenia-zmiany)
-- [Struktura repozytorium](#struktura-repozytorium)
-
----
-
-## Cel projektu
-
-Zaprojektowano jednolity proces CI/CD (build → test → publikacja obrazu → wdrożenie na
-Kubernetes) i zaimplementowano go w **pięciu narzędziach**, a następnie **zmierzono czas
-dostarczenia zmiany** (od commita do działającej aplikacji) dla różnych kombinacji narzędzi
-CI i CD. Celem była obiektywna, ilościowa i jakościowa charakterystyka tych narzędzi.
-
-Proces jest identyczny funkcjonalnie w każdym narzędziu:
-
-1. Uruchomienie po zdarzeniu `push` do repozytorium aplikacji.
-2. Uruchomienie testów jednostkowych (`pytest`).
-3. Zbudowanie obrazu kontenera i opublikowanie go w rejestrze (Azure Container Registry),
-   z tagiem równym SHA commita.
-4. Zaktualizowanie manifestu wdrożenia w repozytorium GitOps (`user-microservice-deploy`) —
-   podmiana taga obrazu na nowy SHA.
-5. Wdrożenie nowej wersji na klaster Kubernetes (Azure AKS) przez narzędzie CD.
-
-## Architektura rozwiązania
-
-```
-        ┌──────────────────────────┐         push          ┌───────────────────────────┐
-        │  user-microservice (Git) │ ────────────────────▶ │        Potok CI           │
-        │  kod aplikacji + potoki  │                       │  Jenkins / Woodpecker /   │
-        └──────────────────────────┘                       │      Argo Workflows       │
-                                                            └────────────┬──────────────┘
-                                                                         │
-                          ┌──────────────────────────────────┬──────────┴───────┐
-                          │ 1. pytest                         │                  │
-                          │ 2. docker build + push            ▼                  ▼
-                          │                       ┌────────────────────┐  ┌───────────────┐
-                          │                       │  Azure Container   │  │  commit taga  │
-                          │                       │  Registry (ACR)    │  │  do repo      │
-                          │                       └────────────────────┘  │  GitOps       │
-                          │                                                └───────┬───────┘
-                          ▼                                                        │
-                                                                                   ▼
-        ┌──────────────────────────┐        obserwuje / webhook       ┌───────────────────────────┐
-        │ user-microservice-deploy │ ◀──────────────────────────────▶│         Potok CD          │
-        │  manifesty K8s (GitOps)  │                                  │  kubectl / ArgoCD / Flux  │
-        └──────────────────────────┘                                  └────────────┬──────────────┘
-                                                                                    │ apply / sync
-                                                                                    ▼
-                                                                        ┌───────────────────────────┐
-                                                                        │   Azure Kubernetes (AKS)  │
-                                                                        │   namespace: user-...     │
-                                                                        └───────────────────────────┘
-```
-
-## Porównywane narzędzia (5)
-
-| Rola | Narzędzie | Model działania |
-|------|-----------|-----------------|
-| **CI** (build/test/push) | **Jenkins** | Potok deklaratywny (`Jenkinsfile`), agent w Kubernetes (pod z wieloma kontenerami) |
-| **CI** | **Woodpecker CI** | Potok YAML (`.woodpecker/build.yaml`), backend Kubernetes |
-| **CI** | **Argo Workflows** | Sterowany zdarzeniami (Argo Events: `EventSource` + `Sensor` → `Workflow`) |
-| **CD** (deploy) | **ArgoCD** | GitOps typu *pull* — synchronizuje stan klastra z repo deploymentowym |
-| **CD** | **FluxCD** | GitOps typu *pull* — `GitRepository` + `Kustomization` + `Receiver` |
-
-Dodatkowo każde narzędzie CI potrafi też pełnić rolę CD w wariancie „to samo narzędzie":
-wdrożenie realizowane jest wtedy imperatywnie przez `kubectl apply` (potok wyzwalany
-commitem do repo GitOps).
-
-## Scenariusze pomiarowe
-
-Pełna macierz to **3 narzędzia CI × 3 warianty CD = 9 scenariuszy**:
-
-| # | CI | CD |
-|---|----|----|
-| Scenariusz 1 | Jenkins | Jenkins (`kubectl apply`) |
-| Scenariusz 2 | Jenkins | ArgoCD |
-| Scenariusz 3 | Jenkins | FluxCD |
-| Scenariusz 4 | Woodpecker | Woodpecker (`kubectl apply`) |
-| Scenariusz 5 | Woodpecker | ArgoCD |
-| Scenariusz 6 | Woodpecker | FluxCD |
-| Scenariusz 7 | Argo Workflows | Argo Workflows |
-| Scenariusz 8 | Argo Workflows | ArgoCD |
-| Scenariusz 9 | Argo Workflows | FluxCD |
-
-> Scenariusze 1–3 obejmują Jenkinsa, 4–6 Woodpeckera, a 7–9 Argo Workflows — w każdej trójce
-> kolejno: to samo narzędzie do CD, ArgoCD oraz FluxCD.
-
-## Mapa branchy
-
-Każda kombinacja narzędzi ma osobny branch — w obu repozytoriach. Poniżej odwzorowanie
-scenariuszy na branche.
-
-**Repozytorium aplikacji (`user-microservice`) — definicje CI:**
-
-| Branch | Zawartość |
-|--------|-----------|
-| `main` | Kod aplikacji (bazowy), ten README, skrypty analizy |
-| `dev` | Gałąź rozwojowa aplikacji + narzędzia pomiarowe (`deployment_timer.sh`, `data_analysis.py`) |
-| `jenkins-pipeline` | CI w Jenkins (`.jenkins/Jenkinsfile`, `podTemplate.yaml`) |
-| `woodpecker` | CI w Woodpecker (`.woodpecker/build.yaml`) |
-| `argo-workflows` | CI w Argo Workflows / Argo Events (`argo-workflows/*`) |
-| `jenkins-fluxcd`, `woodpecker-argocd`, `woodpecker-fluxcd`, `argoworkflow-argocd`, `argoworkflow-fluxcd` | Warianty CI dostrojone do konkretnego narzędzia CD (np. docelowy branch repo GitOps) |
-
-**Repozytorium deploymentowe (`user-microservice-deploy`) — manifesty i CD:**
-
-| Branch | Scenariusz |
-|--------|-----------|
-| `master` | Baza manifestów |
-| `jenkins-kubernetes` | Sc 1 — Jenkins wdraża przez `kubectl` |
-| `jenkins-argocd-deploy` | Sc 2 — ArgoCD |
-| `jenkins-fluxcd-deploy` | Sc 3 — FluxCD |
-| `woodpecker-deploy` | Sc 4 — Woodpecker wdraża przez `kubectl` |
-| `woodpecker-argocd-deploy` | Sc 5 — ArgoCD |
-| `woodpecker-fluxcd-deploy` | Sc 6 — FluxCD |
-| `argo-deploy` | Sc 7 — Argo Workflows |
-| `argoworkflow-argocd` | Sc 8 — ArgoCD |
-| `argoworkflow-fluxcd` / `fluxcd` | Sc 9 — FluxCD |
-
-> Uwaga: warianty FluxCD używają układu katalogów `apps/` + `clusters/prod/` wymaganego przez
-> Flux, pozostałe warianty trzymają manifesty w katalogu głównym repo GitOps.
-
----
-
-## Aplikacja
-
-Mikroserwis udostępnia API REST do zarządzania kontami użytkowników wraz z uwierzytelnianiem
-JWT (tokeny w ciasteczkach), rolami oraz mechanizmem wylogowania (unieważnianie tokenów).
-
-### Stos technologiczny
-
-- **Python 3.11**, **Flask 3**
-- **Flask-JWT-Extended** — uwierzytelnianie JWT
-- **Flask-SQLAlchemy / SQLAlchemy 2** — ORM
-- **MySQL** (produkcyjnie), **SQLite in-memory** (testy)
-- **waitress** — produkcyjny serwer WSGI
-- **pytest** — testy jednostkowe
-- **Docker** — konteneryzacja (obraz bazowy `python:3.11.7-slim-bookworm`)
-
-### API
-
-| Metoda | Ścieżka | Opis | Autoryzacja |
-|--------|---------|------|-------------|
-| `POST` | `/users` | Utworzenie użytkownika | brak (konto `Administrator` wymaga tokena admina) |
-| `GET` | `/users` | Lista wszystkich użytkowników | tylko `Administrator` |
-| `GET` | `/users/<id>` | Szczegóły użytkownika | właściciel lub `Administrator` |
-| `PUT`/`PATCH` | `/users/<id>` | Edycja użytkownika (`PUT` wymaga wszystkich pól) | właściciel lub `Administrator` |
-| `DELETE` | `/users/<id>` | Usunięcie użytkownika | właściciel lub `Administrator` |
-| `POST` | `/login` | Logowanie, ustawia token JWT w ciasteczku | brak |
-| `GET` | `/logout` | Wylogowanie (unieważnienie tokena) | zalogowany |
-| `GET` | `/health` | Sprawdzenie stanu aplikacji i połączenia z bazą | brak *(dostępne na branchach z potokami CI/CD)* |
-| `GET` | `/version` | Zwraca wdrożoną wersję (`APP_VERSION` = SHA commita) i czas budowy | brak *(dostępne na branchach z potokami CI/CD)* |
-
-Przy pierwszym uruchomieniu, jeśli baza jest pusta, tworzone jest domyślne konto administratora
-(zob. zmienne `ADMIN_*`).
-
-### Model danych
-
-- **`User`** — `id`, `username` (unikalny), `email` (unikalny), `role` (`Administrator`/`User`),
-  `password` (hash).
-- **`RevokedToken`** — `jti` unieważnionych tokenów JWT (blocklist przy wylogowaniu).
-
-### Konfiguracja (zmienne środowiskowe)
-
-| Zmienna | Opis | Domyślna |
-|---------|------|----------|
-| `SQLALCHEMY_DATABASE_URI` | Połączenie do bazy MySQL | — (wymagana poza testami) |
-| `JWT_SECRET_KEY` | Klucz podpisujący tokeny JWT | `changeme` |
-| `APP_PORT` | Port serwera | `80` |
-| `ADMIN_USERNAME` | Login domyślnego admina | `admin` |
-| `ADMIN_EMAIL` | E-mail domyślnego admina | `[email protected]` |
-| `ADMIN_PASSWORD` | Hasło domyślnego admina | `admin` |
-
-Produkcyjnie sekrety (`SQLALCHEMY_DATABASE_URI`, hasła MySQL) są dostarczane z **Azure Key
-Vault** przez sterownik CSI `secrets-store` — zob. repozytorium deploymentowe.
-
-### Uruchomienie lokalne
-
-Za pomocą Docker Compose (uruchamia API + MySQL):
-
-```bash
-# przygotuj pliki api/.env oraz db/.env ze zmiennymi środowiskowymi
-docker compose up --build
-```
-
-Bez konteneryzacji:
-
-```bash
-cd api
-python3 -m venv env && source env/bin/activate
-pip install -r requirements.txt
-python3 app.py
-```
-
-Aplikacja czeka na gotowość bazy danych przy starcie (`wait_for_db`, do 100 prób co 3 s).
-
-### Testy
-
-```bash
-cd api
-python3 -m venv env && source env/bin/activate
-pip install -r requirements.txt pytest
-python3 -m pytest
-```
-
-Testy używają bazy SQLite w pamięci (konfiguracja `testing`) i pokrywają operacje CRUD oraz
-uwierzytelnianie. Ten sam zestaw testów jest uruchamiany w każdym potoku CI.
-
-> Wcześniejsze wersje potoków korzystały dodatkowo z testów kontenera **Goss** — zostały one
-> ostatecznie usunięte z potoków (por. historia commitów), a walidację przejęły testy
-> `pytest` oraz health check po wdrożeniu.
-
----
-
-## Potoki CI
-
-Definicje potoków znajdują się na branchach poszczególnych narzędzi. Wszystkie realizują ten
-sam trzyetapowy proces: **testy → build&push → commit do GitOps**.
-
-### Jenkins
-
-Branch `jenkins-pipeline`, plik `.jenkins/Jenkinsfile`. Potok deklaratywny uruchamiany na
-**agencie w Kubernetes** — pod z osobnymi kontenerami do każdego etapu (`podTemplate.yaml`):
-
-- `python` — uruchomienie `pytest` (wyniki jako JUnit XML),
-- `docker` — `docker build` + logowanie do ACR (Azure managed identity) + `docker push`,
-- `git` — sklonowanie repo GitOps, podmiana taga obrazu (`awk`) i commit na branch
-  `jenkins-kubernetes`.
-
-Build kontenera działa bez uprawnień roota dzięki **sysbox** (`runtimeClassName: sysbox-runc`).
-
-### Woodpecker CI
-
-Branch `woodpecker`, plik `.woodpecker/build.yaml`. Trzy kroki (`code-tests`,
-`build-and-push`, `gitops-commit`) na backendzie Kubernetes. Docker-in-Docker uruchamiany
-lokalnie (`dockerd &`) w kontenerze z sysbox. Sekrety (klucz deploy do Gitea, known hosts)
-pobierane z sekretów Woodpeckera.
-
-### Argo Workflows
-
-Branch `argo-workflows`, katalog `argo-workflows/`. Podejście **sterowane zdarzeniami** przez
-Argo Events:
-
-- `source.yaml` — `EventSource` (webhook, dwa endpointy: dla repo aplikacji i deploymentowego),
-- `sensor.yaml` — `Sensor` reagujący na push i tworzący `Workflow` budujący (etapy:
-  `checkout` → `tests` → `build-and-push-image` → `gitops-commit`),
-- `eventbus-default.yaml` — szyna zdarzeń (NATS),
-- `permissions.yaml` — `ServiceAccount` + `Role`/`RoleBinding`,
-- `secret-store.yaml` — dostęp do sekretów z Key Vault.
-
-### Wspólny schemat potoku CI
-
-Wszystkie trzy narzędzia wykonują tę samą logikę, różniąc się jedynie składnią i modelem
-uruchamiania:
-
-```
-push → [pytest] → [docker build → az acr login → docker push (tag = SHA)] → [clone repo GitOps → awk: podmiana tagu → commit → push]
-```
-
-Aktualizacja manifestu w repo GitOps jest realizowana identycznym skryptem `awk`, który
-znajduje kontener `api` i podmienia w nim tag obrazu na SHA nowego commita.
-
-## Infrastruktura
-
-| Element | Zastosowanie |
-|---------|--------------|
-| **Azure Kubernetes Service (AKS)** | Klaster docelowy; działają na nim także agenci CI oraz kontrolery CD |
-| **Azure Container Registry** (`marcin00.azurecr.io`) | Rejestr obrazów |
-| **Azure Key Vault** + CSI `secrets-store` | Dostarczanie sekretów do podów |
-| **Managed Identity** | Bezhasłowe uwierzytelnianie do ACR / AKS / Key Vault |
-| **Gitea** (self-hosted, `gitea.marcin00.pl`) | Repozytoria Git + webhooki wyzwalające potoki |
-| **sysbox** (`sysbox-runc`) | Budowanie obrazów bez uprawnień roota (rootless DinD) |
-| **NGINX Ingress** | Wystawienie aplikacji (`user-microservice.marcin00.pl`) |
-
-## Pomiar dostarczenia zmiany
-
-Metryką porównawczą jest **czas dostarczenia zmiany** — od commita do momentu, w którym nowa
-wersja aplikacji faktycznie działa na klastrze. Pomiar jest w pełni zautomatyzowany, a
-narzędzia znajdują się na branchu **`dev`**:
-
-- **[`deployment_timer.sh`](../../tree/dev/deployment_timer.sh)** — automatyczny pomiar
-  pojedynczego wdrożenia. Skrypt:
-  1. odczytuje aktualną wersję z endpointu `/version`,
-  2. zapisuje znacznik czasu do pliku, commituje go (`Automatyczna zmiana: <timestamp>`)
-     i wykonuje `git push` — co wyzwala cały łańcuch CI/CD,
-  3. odpytuje `/version` co sekundę, aż zwrócona wersja się zmieni,
-  4. zapisuje wynik (`start,koniec,czas,stara_wersja,nowa_wersja`) do pliku
-     `deployment_times.csv`.
-
-  Wykrycie zmiany opiera się na tym, że potok CI buduje obraz z `APP_VERSION` równym SHA
-  commita, a `/version` zwraca tę wartość. Commity `Automatyczna zmiana: <timestamp>` widoczne
-  w historii repozytorium pochodzą właśnie z kolejnych przebiegów tego skryptu.
-
-- **[`data_analysis.py`](../../tree/dev/data_analysis.py)** — agreguje zebrane pomiary
-  (po 20 wdrożeń na scenariusz) i generuje wykresy słupkowe średnich czasów dostarczenia do
-  katalogu `plots/`. Tworzy 6 porównań: trzy według narzędzia CI (dla każdego CD) i trzy
-  według narzędzia CD (dla każdego CI), obejmując wszystkie [9 scenariuszy](#scenariusze-pomiarowe).
-
-  ```bash
-  pip install matplotlib
-  python3 data_analysis.py   # zapisuje plots/mean_times_0..5.png
-  ```
-
-> Pliki wynikowe pomiarów (`deployment_times.csv`, katalog `plots/`) są generowane przez
-> powyższe skrypty i nie są śledzone w repozytorium.
-
-## Struktura repozytorium
-
-```
-user-microservice/
-├── api/
-│   ├── app.py               # fabryka aplikacji Flask, konfiguracja, start serwera waitress
-│   ├── views.py             # endpointy API (użytkownicy, login/logout)
-│   ├── models.py            # modele SQLAlchemy: User, RevokedToken
-│   ├── utils.py             # autoryzacja, oczekiwanie na bazę, inicjalizacja admina
-│   ├── requirements.txt     # zależności aplikacji
-│   └── tests/               # testy pytest (conftest.py, test_users.py)
-├── Dockerfile               # obraz aplikacji
-└── docker-compose.yml       # lokalne uruchomienie API + MySQL
-```
-
-> Definicje potoków CI (`Jenkinsfile`, `.woodpecker/`, `argo-workflows/`) znajdują się na
-> odpowiednich branchach — zob. [Mapa branchy](#mapa-branchy).

api/app.py

@@ -4,7 +4,7 @@ from flask_jwt_extended import JWTManager
 from jwt import ExpiredSignatureError
 from models import db, RevokedToken
 import os
-from utils import init_db, wait_for_db
+from utils import init_db
 from views import user_bp
 from werkzeug.exceptions import HTTPException
 
@@ -53,7 +53,6 @@ def create_app(config_name="default"):
 
     # Fill database by initial values (only if we are not testing)
     with app.app_context():
-        wait_for_db()
         db.create_all()
         if config_name != "testing":
             init_db()

api/utils.py

@@ -2,9 +2,6 @@ from flask import abort
 from flask_jwt_extended import get_jwt_identity
 from models import User, db
 import os
-from sqlalchemy import text
-from sqlalchemy.exc import DatabaseError
-import time
 from werkzeug.security import generate_password_hash
 
 
@@ -30,22 +27,6 @@ def get_user_or_404(user_id):
     return user
 
 
-MAX_RETRIES = 100
-
-def wait_for_db():
-    for retries in range(MAX_RETRIES):
-        try:
-            with db.engine.connect() as connection:
-                connection.execute(text("SELECT 1"))
-            print("Successfully connected with database.")
-            return
-        except DatabaseError:
-            print(f"Waiting for database... (retry {retries + 1})")
-            time.sleep(3)
-    print("Failed to connect to database.")
-    raise Exception("Database not ready after multiple retries.")
-
-
 def init_db():
     """Create default admin account if database is empty"""
     with db.session.begin():

argo-workflows/argo-ingress.yaml

@@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: argo-ingress
+  namespace: argo
+  annotations:
+    nginx.ingress.kubernetes.io/ssl-redirect: "false"
+spec:
+  ingressClassName: nginx
+  rules:
+    - host: argo.marcin00.pl
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: argo-server
+                port:
+                  number: 2746

argo-workflows/eventbus-default.yaml

@@ -0,0 +1,13 @@
+apiVersion: argoproj.io/v1alpha1
+kind: EventBus
+metadata:
+  name: default
+  namespace: argo-events
+spec:
+  nats:
+    native:
+      # Optional, defaults to 3.
+      # If it is < 3, set it to 3, that is the minimal requirement.
+      replicas: 3
+      # Optional, authen strategy, "none" or "token", defaults to "none"
+      auth: token

argo-workflows/permissions.yaml

@@ -0,0 +1,38 @@
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: operate-workflow-sa
+  namespace: argo-events
+
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  name: operate-workflow-role
+  namespace: argo-events
+rules:
+  - apiGroups: [ "argoproj.io" ]
+    resources: [ "workflows" ]
+    verbs: [ "*" ]
+  - apiGroups: [ "argoproj.io" ]
+    resources: [ "workflowtaskresults" ]
+    verbs: [ "create", "patch" ]
+  - apiGroups: [ "" ]
+    resources: [ "pods" ]
+    verbs: [ "get", "patch" ]
+
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: operate-workflow-role-binding
+  namespace: argo-events
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: operate-workflow-role
+subjects:
+  - kind: ServiceAccount
+    name: operate-workflow-sa
+    namespace: argo-events

argo-workflows/secret-store.yaml

@@ -0,0 +1,30 @@
+apiVersion: secrets-store.csi.x-k8s.io/v1
+kind: SecretProviderClass
+metadata:
+  name: azure-keyvault
+  namespace: argo-events
+spec:
+  provider: azure
+  secretObjects:
+    - secretName: gitea-secrets
+      type: Opaque
+      data:
+        - objectName: gitea-known-host
+          key: GITEA_KNOWN_HOST
+        - objectName: gitea-deploy-key
+          key: GITEA_DEPLOY_KEY
+  parameters:
+    usePodIdentity: "false"
+    useVMManagedIdentity: "true"
+    userAssignedIdentityID: "f91aef65-7d2a-4df8-a884-e33b05d54a31" # client_id of the user-assigned managed identity
+    clientID: "f91aef65-7d2a-4df8-a884-e33b05d54a31"               # client_id of the user-assigned managed identity
+    keyvaultName: "dev-aks"
+    objects:  |
+      array:
+        - |
+          objectName: gitea-known-host
+          objectType: secret
+        - |
+          objectName: gitea-deploy-key
+          objectType: secret
+    tenantID: "f4e3e6f7-d21c-460e-b201-2192174e7f41"

argo-workflows/sensor.yaml

@@ -0,0 +1,172 @@
+apiVersion: argoproj.io/v1alpha1
+kind: Sensor
+metadata:
+  name: webhook-build
+  namespace: argo-events
+spec:
+  template:
+    serviceAccountName: operate-workflow-sa
+  dependencies:
+    - name: gitea-push
+      eventSourceName: webhook
+      eventName: test-hook
+  triggers:
+    - template:
+        name: trigger-build-workflow
+        k8s:
+          group: argoproj.io
+          version: v1alpha1
+          resource: workflows
+          operation: create
+          source:
+            resource:
+              apiVersion: argoproj.io/v1alpha1
+              kind: Workflow
+              metadata:
+                generateName: build-workflow-
+                namespace: argo-events
+              spec:
+                entrypoint: main
+                serviceAccountName: operate-workflow-sa
+                volumeClaimTemplates:
+                  - metadata:
+                      name: workspace
+                    spec:
+                      accessModes: ["ReadWriteOnce"]
+                      resources:
+                        requests:
+                          storage: 128Mi
+                volumes:
+                  - name: secrets-store
+                    csi:
+                      driver: secrets-store.csi.k8s.io
+                      readOnly: true
+                      volumeAttributes:
+                        secretProviderClass: azure-keyvault
+                templates:
+                  - name: main
+                    steps:
+                      - - name: checkout
+                          template: checkout
+                      - - name: tests
+                          template: tests
+                      - - name: build-and-push-image
+                          template: build-and-push-image
+                          arguments:
+                            parameters:
+                              - name: git-sha
+                                value: "{{steps.checkout.outputs.parameters.git-sha}}"
+                      - - name: gitops-commit
+                          template: gitops-commit
+                          arguments:
+                            parameters:
+                              - name: git-sha
+                                value: "{{steps.checkout.outputs.parameters.git-sha}}"
+                  - name: checkout
+                    container:
+                      image: alpine/git
+                      command: [sh, -c]
+                      workingDir: /workspace
+                      env:
+                        - name: REPO_URL
+                          value: https://gitea.marcin00.pl/pikram/user-microservice.git
+                        - name: REPO_BRANCH
+                          value: argo-workflow
+                      args:
+                        - |
+                          git clone --depth 1 --branch "${REPO_BRANCH}" --single-branch "${REPO_URL}" repo
+                          cd repo
+                          git rev-parse HEAD > /tmp/gitsha.txt
+                      volumeMounts:
+                        - name: workspace
+                          mountPath: /workspace
+                    outputs:
+                      parameters:
+                        - name: git-sha
+                          valueFrom:
+                            path: /tmp/gitsha.txt
+                  - name: tests
+                    script:
+                      image: python:3.11.7-alpine
+                      command: [sh]
+                      workingDir: /workspace/repo/api
+                      source: |
+                        python3 -m venv env
+                        source env/bin/activate
+                        pip install -r requirements.txt pytest
+                        python3 -m pytest --junit-xml=pytest_junit.xml
+                      volumeMounts:
+                        - name: workspace
+                          mountPath: /workspace
+                  - name: build-and-push-image
+                    inputs:
+                      parameters:
+                        - name: git-sha
+                    podSpecPatch: |
+                      runtimeClassName: sysbox-runc
+                    metadata:
+                      annotations:
+                        io.kubernetes.cri-o.userns-mode: "auto:size=65536"
+                    container:
+                      image: marcin00.azurecr.io/azure-cli-docker:slim-bookworm
+                      command: [sh, -c]
+                      workingDir: /workspace/repo
+                      env:
+                        - name: DOCKER_IMAGE
+                          value: marcin00.azurecr.io/user-microservice:{{inputs.parameters.git-sha}}
+                        - name: CLIENT_ID
+                          value: c302726f-fafb-4143-94c1-67a70975574a
+                        - name: ACR_NAME
+                          value: marcin00
+                      args:
+                        - |
+                          dockerd &
+                          docker build -t $DOCKER_IMAGE --build-arg APP_VERSION={{inputs.parameters.git-sha}} --build-arg BUILD_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ") .
+                          az login --identity --client-id ${CLIENT_ID}
+                          az acr login --name ${ACR_NAME}
+                          docker push ${DOCKER_IMAGE}
+                      volumeMounts:
+                        - name: workspace
+                          mountPath: /workspace
+                  - name: gitops-commit
+                    inputs:
+                      parameters:
+                        - name: git-sha
+                    container:
+                      image: alpine/git
+                      command: [sh, -c]
+                      env:
+                        - name: DEPLOY_REPO_URL
+                          value: ssh://[email protected]:20343/pikram/user-microservice-deploy.git
+                        - name: DEPLOY_REPO_BRANCH
+                          value: argo-deploy
+                        - name: CI_COMMIT_SHA
+                          value: "{{inputs.parameters.git-sha}}"
+                      args:
+                        - |
+                          mkdir -p ~/.ssh
+                          cp /mnt/secrets/gitea-known-host ~/.ssh/known_hosts
+                          chmod 644 ~/.ssh/known_hosts
+                          cp /mnt/secrets/gitea-deploy-key ~/.ssh/id_ed25519
+                          chmod 600 ~/.ssh/id_ed25519
+                          git config --global user.name "argo[bot]"
+                          git config --global user.email "[email protected]"
+                          git clone --depth 1 --branch $DEPLOY_REPO_BRANCH --single-branch $DEPLOY_REPO_URL repo
+                          cd repo
+                          awk -v commit="$CI_COMMIT_SHA" '
+                          $0 ~ /name:[[:space:]]*api/ { in_api_container = 1; print; next }
+                          in_api_container && $0 ~ /^[[:space:]]*image:[[:space:]]*/ {
+                              sub(/:[^:[:space:]]+$/, ":" commit)
+                              in_api_container = 0
+                              print
+                              next
+                          }
+                          { print }
+                          ' deploy.yaml > deploy.tmp && mv deploy.tmp deploy.yaml
+                          git add deploy.yaml
+                          git diff-index --quiet HEAD || git commit -m "Argo: Changed deployed version to $CI_COMMIT_SHA"
+                          git push origin $DEPLOY_REPO_BRANCH
+                      volumeMounts:
+                        - name: secrets-store
+                          mountPath: "/mnt/secrets"
+                          readOnly: true

argo-workflows/source.yaml

@@ -0,0 +1,15 @@
+apiVersion: argoproj.io/v1alpha1
+kind: EventSource
+metadata:
+  name: webhook
+  namespace: argo-events
+spec:
+  service:
+    ports:
+    - port: 12000
+      targetPort: 12000
+  webhook:
+    test-hook:
+      endpoint: /gitea-hook
+      method: POST
+      port: "12000"

argo-workflows/webhook-ingress.yaml

@@ -0,0 +1,20 @@
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: argo-ingress
+  namespace: argo-events
+  annotations:
+    nginx.ingress.kubernetes.io/ssl-redirect: "false"
+spec:
+  ingressClassName: nginx
+  rules:
+    - host: argo-hook.marcin00.pl
+      http:
+        paths:
+          - path: /gitea-hook
+            pathType: Prefix
+            backend:
+              service:
+                name: webhook-eventsource-svc
+                port:
+                  number: 12000

argo-workflows/webhook-service.yaml

@@ -0,0 +1,16 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: webhook-eventsource-svc
+  namespace: argo-events
+spec:
+  type: ClusterIP
+  ports:
+  - name: default
+    port: 12000
+    protocol: TCP
+    targetPort: 12000
+  selector:
+    controller: eventsource-controller
+    eventsource-name: webhook
+    owner-name: webhook