|
| 1 | +# GitHub Workflows |
| 2 | + |
| 3 | +Two GitHub Actions workflows automate dependency management and pull request documentation. |
| 4 | + |
| 5 | +## Dependency Update Check |
| 6 | + |
| 7 | +**File:** `.github/workflows/dependency-update.yml` |
| 8 | + |
| 9 | +Checks vendor dependencies for newer versions and opens a PR when updates are available. |
| 10 | + |
| 11 | +### How it works |
| 12 | + |
| 13 | +1. Reads `dependencies.json` (the single source of truth for vendor library versions) |
| 14 | +2. Queries the npm registry for each dependency |
| 15 | +3. Finds the latest version within the same major range (e.g., 5.24.0 → 5.25.0, but not 6.0.0) |
| 16 | +4. If updates exist: bumps versions in `dependencies.json`, deletes old vendor files, commits to a new branch, and opens a PR |
| 17 | +5. If everything is current: logs "All dependencies are up to date" and exits |
| 18 | + |
| 19 | +### Schedule |
| 20 | + |
| 21 | +- **Automatic:** Every Monday at 9:00 AM UTC |
| 22 | +- **Manual:** Actions tab → "Dependency Update Check" → Run workflow |
| 23 | + |
| 24 | +### What the PR contains |
| 25 | + |
| 26 | +- Updated `dependencies.json` with new version numbers |
| 27 | +- Deleted vendor files (so `serve.py` re-downloads the new versions on next start) |
| 28 | +- A table showing each package, old version, and new version |
| 29 | + |
| 30 | +### Adding a new dependency |
| 31 | + |
| 32 | +Add an entry to `dependencies.json`: |
| 33 | + |
| 34 | +```json |
| 35 | +{ |
| 36 | + "name": "package-name", |
| 37 | + "version": "1.0.0", |
| 38 | + "files": { |
| 39 | + "local-filename.js": "https://unpkg.com/package-name@{{version}}/dist/file.js" |
| 40 | + }, |
| 41 | + "registry": "npm" |
| 42 | +} |
| 43 | +``` |
| 44 | + |
| 45 | +The `{{version}}` placeholder is replaced by `serve.py` when downloading and by the workflow when checking for updates. |
| 46 | + |
| 47 | +### Why same-major only |
| 48 | + |
| 49 | +Major version bumps (e.g., MapLibre 5.x → 6.x) often have breaking API changes that require manual code updates. The workflow only suggests minor/patch bumps that should be safe to merge without code changes. |
| 50 | + |
| 51 | +--- |
| 52 | + |
| 53 | +## PR Summary |
| 54 | + |
| 55 | +**File:** `.github/workflows/pr-summary.yml` |
| 56 | + |
| 57 | +Automatically posts a summary comment on every pull request, including an AI-generated description of the changes. |
| 58 | + |
| 59 | +### How it works |
| 60 | + |
| 61 | +1. Triggered when a PR is opened or updated (`pull_request_target`) |
| 62 | +2. Fetches the PR metadata, commit messages, and file diffs |
| 63 | +3. Sends the diff context to GitHub Models API (`openai/gpt-4o-mini`) to generate a 3-5 sentence natural-language description |
| 64 | +4. Posts a comment on the PR with: |
| 65 | + - PR title, author, and draft status |
| 66 | + - Total additions/deletions |
| 67 | + - AI-generated description of functional changes |
| 68 | + - Per-file breakdown showing new/modified functions |
| 69 | + |
| 70 | +### Configuration |
| 71 | + |
| 72 | +Requires a `MODELS_TOKEN` secret in the repository (or organization) settings. This token authenticates with the [GitHub Models API](https://github.com/marketplace/models). |
| 73 | + |
| 74 | +### What it skips |
| 75 | + |
| 76 | +- `.github/`, `.circleci/`, `.gitlab/` directories are excluded from the AI summary context and file list |
| 77 | +- Merge commits are filtered from the commit message list |
| 78 | +- Diffs are truncated to keep the AI prompt within token limits (1500 chars per file, max 12 files) |
| 79 | + |
| 80 | +### Why `pull_request_target` |
| 81 | + |
| 82 | +This trigger runs the workflow from the base branch (main), not the PR branch. This ensures the workflow always has access to repository secrets (`MODELS_TOKEN`), even for PRs from forks or new branches. |
0 commit comments