Add CI Pipeline with Tests and Docker build

.github/workflows/ci_papeline.yaml

@@ -0,0 +1,77 @@
+name: MLOps CI Pipeline
+
+# 1. TRIGGER: Quando deve partire questa pipeline?
+# Parte su ogni "push" sul ramo main e su ogni "pull request"
+on:
+  push:
+    branches: [ "main" ]
+  pull_request:
+    branches: [ "main" ]
+
+# Appena attivato il trigger, viene avviato build docker sotto che richieste l'esecuzione di run_test, se ok parte la creazione dell'immagine docker
+jobs:
+  # JOB 1: Esecuzione dei Test Automatici
+  run_tests:
+    runs-on: ubuntu-latest # Usa una macchina Linux di GitHub
+    
+    steps:
+    # A. Scarica il codice dalla tua repository
+    - name: Checkout code
+      uses: actions/checkout@v3 # serve proprio a dire al robot di GitHub: "Scarica la versione del codice contenuta in questo specifico commit che ha appena fatto scattare il trigger".
+      # Dobbiamo testare sui nuovi file che stiamo pushando, per questo ci assicuriamo di farlo con i nuovi file
+
+    # B. Installa Python 3.9 (lo stesso del Dockerfile)
+    - name: Set up Python 3.9
+      uses: actions/setup-python@v4
+      with:
+        python-version: "3.9"
+        cache: 'pip' # <--- FONDAMENTALE: Cacha le librerie (così non riscarica le dipendenze ogni volta)
+
+    # C. Installa le librerie
+    - name: Install dependencies
+      run: |
+        python -m pip install --upgrade pip
+        pip install -r requirements.txt
+
+    # D. Lancia Pytest
+    - name: Run Tests
+      run: |
+        python -m pytest
+
+  # JOB 2: Verifica della Build Docker
+  # Questo job parte SOLO se "run_tests" ha successo (needs: run_tests)
+  build_docker:
+    needs: run_tests
+    runs-on: ubuntu-latest
+    
+    steps:
+    - name: Checkout code
+      uses: actions/checkout@v3
+      
+    - name: Build Docker Image
+      # Prova a costruire l'immagine. Se il Dockerfile è rotto, questo step fallisce.
+      # E' solo un test, dopo che abbiamo fatto girare pytest su test_api.py, ora testiamo che il dockerfile funzioni creando l'immmagine che poi distruggiamo
+      run: docker build -t reputation-monitor:test .
+
+"""
+I file vengono salvati nella repository PRIMA che il test parta. È il fatto che tu abbia "pushato" i file che sveglia il robot e gli fa iniziare il lavoro.
+
+Ecco la sequenza temporale esatta:
+
+⏳ La Timeline Reale
+Tu fai git push: I tuoi file vengono caricati su GitHub. In questo istante, il codice nella repository è già aggiornato (anche se fosse rotto).
+
+GitHub vede il cambiamento: "Ehi, è arrivato nuovo codice! Devo lanciare la pipeline".
+
+Parte la CI (Test & Build): GitHub scarica quel codice appena caricato ed esegue i test e la build Docker.
+
+Esito:
+
+🟢 Se passa: Accanto al tuo commit compare una spunta verde. Tutto bene.
+
+🔴 Se fallisce: Accanto al tuo commit compare una croce rossa. MA i file restano lì. GitHub non cancella il tuo codice se il test fallisce; ti avvisa solo che è "bacato".
+
+Se il codice rotto viene caricato comunque, a che serve il test?
+
+Professionalmente si crea un ramo diverso della repository, un nuovo branch che non va in produzione, e si pusha li facendo partire CI/CD. POi se tutto ok viene anche aggiornato il main che è sacro
+"""

Dockerfile

@@ -0,0 +1,32 @@
+# 1. Usiamo un'immagine base ufficiale di Python (leggera e sicura)
+FROM python:3.9-slim
+
+# 2. Impostiamo la cartella di lavoro dentro il container
+WORKDIR /code
+
+# 3. Ottimizzazione della Cache:
+# Copiamo PRIMA solo i requirements. Questo permette a Docker di non
+# riscaricare tutte le librerie se cambi solo il codice ma non le dipendenze.
+COPY ./requirements.txt /code/requirements.txt
+
+# 4. Installiamo le dipendenze
+# --no-cache-dir serve a mantenere l'immagine leggera
+RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
+
+# 5. Copiamo tutto il resto del codice dentro il container
+COPY ./app /code/app
+
+# 6. (Opzionale ma consigliato) Scarichiamo il modello durante la build
+# In MLOps avanzato si fa per evitare che il container debba scaricare 
+# 500MB ogni volta che si avvia.
+# Creiamo un piccolo script inline per fare il "pre-load"
+RUN python -c "from transformers import AutoTokenizer, AutoModelForSequenceClassification; \
+    name='cardiffnlp/twitter-roberta-base-sentiment-latest'; \
+    AutoTokenizer.from_pretrained(name); \
+    AutoModelForSequenceClassification.from_pretrained(name)"
+
+# 7. Esponiamo la porta 8000
+EXPOSE 8000
+
+# 8. Il comando che parte quando avvii il container
+CMD ["uvicorn", "app.api.main:app", "--host", "0.0.0.0", "--port", "8000"]

app/__init__.py

@@ -0,0 +1,23 @@
+"""
+SPIEGAZIONE DI QUESTO FILE
+
+Immagina le cartelle del tuo computer come delle semplici scatole. Per Python, una cartella è solo una scatola "muta": non sa che dentro c'è del codice collegato che può essere usato altrove.
+
+Il file __init__.py serve a trasformare quella scatola in un Pacchetto (Package).
+
+1. La metafora della "Bandiera" 🚩
+Pensa al file __init__.py come a una bandiera piantata sopra la cartella che dice a Python:
+
+"Ehi! Questa non è una cartella qualsiasi piena di file a caso. Questa è una libreria di codice Python! Puoi entrare qui e importare le funzioni che trovi."
+
+2. Cosa fa tecnicamente?
+Senza __init__.py: Se scrivi from app.api import main, Python potrebbe dirti "Non trovo app", perché la tratta come una semplice directory di file.
+
+Con __init__.py: Python riconosce app come un oggetto importabile e ti permette di navigare al suo interno con il punto (.).
+
+3. Perché ti serviva per i test?
+Quando hai lanciato pytest, lui doveva collegare due mondi separati: la cartella tests e la cartella app. Mettendo __init__.py, hai detto a Python che tutto il tuo progetto è un insieme di moduli collegati, permettendo al file di test di "vedere" e importare il codice della tua applicazione principale.
+
+Nota: Il file può essere (e spesso è) completamente vuoto. La sua sola presenza è sufficiente a fare la magia.
+
+"""

app/api/__init__.py

@@ -0,0 +1,23 @@
+"""
+SPIEGAZIONE DI QUESTO FILE
+
+Immagina le cartelle del tuo computer come delle semplici scatole. Per Python, una cartella è solo una scatola "muta": non sa che dentro c'è del codice collegato che può essere usato altrove.
+
+Il file __init__.py serve a trasformare quella scatola in un Pacchetto (Package).
+
+1. La metafora della "Bandiera" 🚩
+Pensa al file __init__.py come a una bandiera piantata sopra la cartella che dice a Python:
+
+"Ehi! Questa non è una cartella qualsiasi piena di file a caso. Questa è una libreria di codice Python! Puoi entrare qui e importare le funzioni che trovi."
+
+2. Cosa fa tecnicamente?
+Senza __init__.py: Se scrivi from app.api import main, Python potrebbe dirti "Non trovo app", perché la tratta come una semplice directory di file.
+
+Con __init__.py: Python riconosce app come un oggetto importabile e ti permette di navigare al suo interno con il punto (.).
+
+3. Perché ti serviva per i test?
+Quando hai lanciato pytest, lui doveva collegare due mondi separati: la cartella tests e la cartella app. Mettendo __init__.py, hai detto a Python che tutto il tuo progetto è un insieme di moduli collegati, permettendo al file di test di "vedere" e importare il codice della tua applicazione principale.
+
+Nota: Il file può essere (e spesso è) completamente vuoto. La sua sola presenza è sufficiente a fare la magia.
+
+"""

app/api/main.py

@@ -29,7 +29,12 @@ def home():
 # Serve a capire se il container è vivo
 @app.get("/health")
 def health_check():
-    return {"status": "ok", "message": "Service is running"}
+    # VERIFICA: Controlliamo se il modello è stato caricato in memoria
+    if model_instance.model is not None:
+        return {"status": "ok", "model_loaded": True}
+    else:
+        # Se il modello non c'è, restituiamo errore 503 (Service Unavailable)
+        raise HTTPException(status_code=503, detail="Model not loaded yet")
 
 # 5. Endpoint di Previsione (Dummy per ora)
 @app.post("/predict", response_model=SentimentResponse)

app/model/__init__.py

@@ -0,0 +1,23 @@
+"""
+SPIEGAZIONE DI QUESTO FILE
+
+Immagina le cartelle del tuo computer come delle semplici scatole. Per Python, una cartella è solo una scatola "muta": non sa che dentro c'è del codice collegato che può essere usato altrove.
+
+Il file __init__.py serve a trasformare quella scatola in un Pacchetto (Package).
+
+1. La metafora della "Bandiera" 🚩
+Pensa al file __init__.py come a una bandiera piantata sopra la cartella che dice a Python:
+
+"Ehi! Questa non è una cartella qualsiasi piena di file a caso. Questa è una libreria di codice Python! Puoi entrare qui e importare le funzioni che trovi."
+
+2. Cosa fa tecnicamente?
+Senza __init__.py: Se scrivi from app.api import main, Python potrebbe dirti "Non trovo app", perché la tratta come una semplice directory di file.
+
+Con __init__.py: Python riconosce app come un oggetto importabile e ti permette di navigare al suo interno con il punto (.).
+
+3. Perché ti serviva per i test?
+Quando hai lanciato pytest, lui doveva collegare due mondi separati: la cartella tests e la cartella app. Mettendo __init__.py, hai detto a Python che tutto il tuo progetto è un insieme di moduli collegati, permettendo al file di test di "vedere" e importare il codice della tua applicazione principale.
+
+Nota: Il file può essere (e spesso è) completamente vuoto. La sua sola presenza è sufficiente a fare la magia.
+
+"""

requirements.txt

@@ -16,4 +16,4 @@ numpy
 
 # --- Testing ---
 pytest
-httpx
+httpx==0.27.0

tests/__init__.py

@@ -0,0 +1,23 @@
+"""
+SPIEGAZIONE DI QUESTO FILE
+
+Immagina le cartelle del tuo computer come delle semplici scatole. Per Python, una cartella è solo una scatola "muta": non sa che dentro c'è del codice collegato che può essere usato altrove.
+
+Il file __init__.py serve a trasformare quella scatola in un Pacchetto (Package).
+
+1. La metafora della "Bandiera" 🚩
+Pensa al file __init__.py come a una bandiera piantata sopra la cartella che dice a Python:
+
+"Ehi! Questa non è una cartella qualsiasi piena di file a caso. Questa è una libreria di codice Python! Puoi entrare qui e importare le funzioni che trovi."
+
+2. Cosa fa tecnicamente?
+Senza __init__.py: Se scrivi from app.api import main, Python potrebbe dirti "Non trovo app", perché la tratta come una semplice directory di file.
+
+Con __init__.py: Python riconosce app come un oggetto importabile e ti permette di navigare al suo interno con il punto (.).
+
+3. Perché ti serviva per i test?
+Quando hai lanciato pytest, lui doveva collegare due mondi separati: la cartella tests e la cartella app. Mettendo __init__.py, hai detto a Python che tutto il tuo progetto è un insieme di moduli collegati, permettendo al file di test di "vedere" e importare il codice della tua applicazione principale.
+
+Nota: Il file può essere (e spesso è) completamente vuoto. La sua sola presenza è sufficiente a fare la magia.
+
+"""

tests/test_api.py

@@ -0,0 +1,40 @@
+from fastapi.testclient import TestClient
+from app.api.main import app
+
+# Creiamo un client di test (simula il browser)
+client = TestClient(app)
+
+def test_health_check():
+    """Verifica che l'endpoint /health risponda status 200"""
+    response = client.get("/health")
+    assert response.status_code == 200
+    assert response.json() == {"status": "ok", "model_loaded": True}
+
+def test_prediction_positive():
+    """Verifica che il modello riconosca un sentimento positivo"""
+    payload = {"text": "I love this service, it is amazing!"}
+    response = client.post("/predict", json=payload)
+    
+    assert response.status_code == 200
+    json_data = response.json()
+    assert "sentiment" in json_data
+    assert "confidence" in json_data
+    # Ci aspettiamo che sia positivo (o almeno non negativo)
+    assert json_data["sentiment"] == "positive"
+
+def test_prediction_negative():
+    """Verifica che il modello riconosca un sentimento negativo"""
+    payload = {"text": "This is terrible, I hate it."}
+    response = client.post("/predict", json=payload)
+    
+    assert response.status_code == 200
+    assert response.json()["sentiment"] == "negative"
+
+
+"""
+scrivi sul terminale:   pytest    Serve per lanciare il test
+Oppure: pytest -v per vedere tutti i dettagli
+
+P.S: pytest agisce come un detective, quando lancio il comando scanziona la cartella corrente
+e cerca file che iniziano con "test_" o finiscono con "_test.py", una volta entrato nel file lancia solo le funzioni che iniziano con "test_"
+"""