Add Flutter CI workflow and beginner docs

.github/workflows/flutter-ci.yml

@@ -0,0 +1,42 @@
+# Flutter CI – runs on every push and pull request to main
+# Used in this course to demonstrate GitHub Actions and automated testing.
+
+name: Flutter CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  build-and-test:
+    runs-on: ubuntu-latest
+    env:
+      FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Set up Flutter
+        uses: subosito/flutter-action@v2
+        with:
+          channel: stable
+          cache: true
+
+      - name: Get dependencies
+        working-directory: task_manager_app
+        run: flutter pub get
+
+      - name: Analyze code
+        working-directory: task_manager_app
+        run: flutter analyze
+
+      - name: Run tests
+        working-directory: task_manager_app
+        run: flutter test
+
+      - name: Build app
+        working-directory: task_manager_app
+        run: flutter build apk --debug

.gitignore

@@ -13,3 +13,6 @@ task_manager_app/.flutter-plugins-dependencies
 # OS
 .DS_Store
 Thumbs.db
+
+# Node / npm
+package-lock.json

CICD_FOR_STUDENTS.md

@@ -0,0 +1,169 @@
+# Simple CI/CD Flow – For Teaching (Mobile App Development)
+
+This document explains the CI/CD pipeline in a way you can use directly with students. Use it as a lecture guide or share it with them as a handout.
+
+---
+
+## 1. The Five-Step Flow (Explain It Like This)
+
+### 1️⃣ Developer Writes Code
+
+A developer writes code on their machine.
+
+**Examples:**
+
+- Add a new feature  
+- Fix a bug  
+- Improve the UI  
+
+Then they **commit** the code.
+
+---
+
+### 2️⃣ Code Is Pushed to the Repository
+
+The developer runs:
+
+```bash
+git push
+```
+
+The code goes to a **remote repository** (e.g. GitHub).
+
+---
+
+### 3️⃣ CI Pipeline Starts Automatically
+
+When code is pushed:
+
+1. **GitHub** detects the change  
+2. The **GitHub Actions** workflow starts  
+
+This happens because of the file:
+
+```
+.github/workflows/flutter-ci.yml
+```
+
+No one has to click “Run” — it starts automatically.
+
+---
+
+### 4️⃣ Automated Steps Run
+
+The pipeline runs steps like:
+
+- Install dependencies  
+- Run static analysis  
+- Run tests  
+- Build the app  
+
+For our Flutter project that means:
+
+- `flutter pub get`  
+- `flutter analyze`  
+- `flutter test`  
+- `flutter build`  
+
+**No human intervention required.**
+
+---
+
+### 5️⃣ Results Are Reported
+
+The system shows:
+
+- ✅ **Build passed**  
+- ❌ **Build failed**  
+
+If something breaks, developers see it immediately (e.g. in the GitHub **Actions** tab or on the pull request).
+
+---
+
+## 2. CI vs CD (Explain This Clearly)
+
+Students often confuse these. Keep the distinction simple:
+
+### CI — Continuous Integration
+
+- **Means:** Automatically **build** and **test** code whenever developers push changes.  
+- **Purpose:**  
+  - Detect bugs early  
+  - Make sure the code always builds  
+
+### CD — Continuous Delivery / Deployment
+
+- **Means:** Automatically **deliver** or **deploy** the application.  
+- **Examples:**  
+  - Build APK / IPA  
+  - Upload to a testing environment  
+  - Release to the store  
+
+For mobile apps, CD might use tools like **Fastlane**, **Expo EAS**, or store deployment pipelines.
+
+**In this course we focus on CI** (build + test). CD is the next step in real-world teams.
+
+---
+
+## 3. One-Sentence Explanation (Students Remember This)
+
+You can tell students:
+
+> **“CI/CD is like a robot developer that checks our code every time we push changes.”**
+
+That analogy usually makes the idea click.
+
+---
+
+## 4. Example Flow in This Course
+
+Use this in your lecture:
+
+1. **Student writes code** (e.g. a small change in the app or a test).  
+2. **Commit** the change.  
+3. **Push** to GitHub.  
+4. **GitHub Actions** runs our CI workflow.  
+5. **Tests** run.  
+6. **Build** is verified.  
+7. **Result** is shown in the **Actions** tab.
+
+---
+
+## 5. Live Demo (Students Love This)
+
+During the lecture:
+
+1. Make a **small commit** (e.g. `docs: update README` or change one line in the app).  
+2. **Push** it.  
+3. Open the **Actions** tab on GitHub.  
+4. Show the pipeline running **live**.  
+
+That moment usually makes CI/CD click instantly.
+
+---
+
+## 6. Optional: What Big Companies Do (If Students Ask)
+
+Explain that in industry, pipelines often include:
+
+- **Build**  
+- **Test**  
+- **Security scan**  
+- **Code quality checks**  
+- **Deployment**  
+- **Monitoring**  
+
+So CI/CD becomes the **backbone** of modern software engineering. Our course pipeline is a simplified version of the same idea.
+
+---
+
+## Quick Reference
+
+| Term        | Meaning in one line                                      |
+|------------|-----------------------------------------------------------|
+| **CI**     | Automatically build and test when code is pushed.         |
+| **CD**     | Automatically deliver or deploy the app.                 |
+| **Workflow** | The set of steps defined in `.github/workflows/`.     |
+| **Actions tab** | Where you see runs and results on GitHub.           |
+
+For more detail on what runs in *this* repo, see **CI_EXPLANATION.md**.

CI_EXPLANATION.md

@@ -0,0 +1,58 @@
+# CI (Continuous Integration) – Beginner Guide
+
+This file explains what CI is and how it works in this repository.
+
+## What is CI?
+
+**Continuous Integration (CI)** means we automatically run checks every time code changes.
+
+Instead of waiting until the end of the week (or the end of the project) to find problems, CI helps us find problems early.
+
+## What is GitHub Actions?
+
+**GitHub Actions** is a tool inside GitHub that runs automated workflows.
+
+Workflows are defined in YAML files inside:
+
+```
+.github/workflows/
+```
+
+## What happens when you push code?
+
+When you:
+
+- push to `main`, or
+- open/update a pull request (PR) targeting `main`
+
+GitHub Actions runs our **Flutter CI** workflow.
+
+In this repository, the workflow:
+
+1. Checks out the code
+2. Installs Flutter
+3. Runs `flutter pub get`
+4. Runs `flutter analyze`
+5. Runs `flutter test`
+6. Attempts to build the app
+
+If all steps pass, the run is **green**. If any step fails, it is **red**.
+
+## Why builds and tests matter in real teams
+
+In real software teams:
+
+- many people change the same codebase
+- mistakes happen (even to experienced developers)
+
+Automated tests and builds help teams:
+
+- catch errors before merging code
+- keep the `main` branch stable
+- release software with more confidence
+
+CI does not guarantee “no bugs”, but it catches many common problems early (broken builds, failed tests, analysis warnings/errors).
+
+---
+
+**For lecturers:** A longer teaching guide with the full CI/CD flow, CI vs CD, and live-demo tips is in **CICD_FOR_STUDENTS.md**.

CONTRIBUTING.md

@@ -0,0 +1,73 @@
+# Contributing – Git workflow for this course
+
+This guide explains the **Git workflow** you should follow when working on this repository. We use a simple **feature-branch + pull request** workflow so everyone’s work stays organized and reviewable.
+
+## Workflow in short
+
+- Update your local `main`
+- Create a feature branch
+- Make small commits with clear messages
+- Push your branch
+- Open a pull request (PR) to `main`
+- Ensure CI is green, then merge
+
+Avoid committing directly to `main` for shared work.
+
+## Create a feature branch
+
+Start from an up-to-date `main`:
+
+```bash
+git checkout main
+git pull origin main
+```
+
+Create and switch to a new branch:
+
+```bash
+git checkout -b feature/add-login-screen
+```
+
+Branch naming ideas:
+
+- `feature/...` for new features
+- `fix/...` for bug fixes
+- `docs/...` for documentation
+
+## Commit message format
+
+Write commit messages that are easy to understand.
+
+**Format:**
+
+```
+Short summary (imperative, no period)
+
+Optional details: what changed and why.
+```
+
+Examples:
+
+- `Add login screen UI`
+- `Fix validation on empty task title`
+- `Add Flutter CI workflow`
+
+## Open a pull request
+
+Push your branch:
+
+```bash
+git push -u origin feature/add-login-screen
+```
+
+Then on GitHub:
+
+- Open a **Pull Request** targeting `main`
+- Add a clear title and short description
+- Wait for **CI checks** to finish
+- If something fails, fix it and push again (the PR updates automatically)
+
+## What to do if CI fails
+
+CI failures are normal while learning. Read the logs in the GitHub **Actions** tab (or in the PR checks), fix the issue locally, then commit and push again.
+