Replace deprecated facebook/pyre-action with direct Pyre execution in CI

[Copilot]

The Pyre workflow was failing before analysis started because facebook/pyre-action transitively depended on deprecated actions/upload-artifact@v2, which GitHub now blocks. This change removes that dependency path and runs Pyre directly in the workflow.

• Workflow dependency path cleanup

  • Removed facebook/pyre-action@60697a7858f7cc8470d8cc494a3cf2ad6b06560d from .github/workflows/pyre.yml.
  • Kept job trigger and permissions model intact.

• Direct Pyre setup/execution

  • Added actions/setup-python@v5 with Python 3.11.
  • Added shell-based dependency installation (pip, optional requirements.txt, pyre-check).
  • Replaced action invocation with pyre check.

• Resulting CI behavior

  • Pyre now runs via first-party setup + explicit commands, avoiding blocked transitive actions and keeping the check logic in-repo and transparent.

- name: Set up Python
  uses: actions/setup-python@v5
  with:
    python-version: '3.11'

- name: Install dependencies
  run: |
    python -m pip install --upgrade pip
    if [ -f requirements.txt ]; then
      pip install -r requirements.txt
    fi
    pip install pyre-check

- name: Run Pyre
  run: pyre check

[Pmaster-dev]

or replacew blocks of adding modei,comute,snipper,programmic jsond fi!e on srver ? exhausive list server lik caddy deno supabas w llm? CHECK PINKVAI IN PINKYCOLLIE

[qodo-code-review]

PR Summary by Qodo

Run Pyre directly in CI to avoid deprecated facebook/pyre-action dependencies

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Remove facebook/pyre-action to avoid blocked deprecated transitive GitHub Actions.
• Set up Python 3.11 and install pyre-check via pip within the workflow.
• Run pyre check directly for transparent, in-repo CI behavior.

Diagram

graph TD
  A["GitHub Actions: pyre.yml"] --> B["Runner"] --> C["Setup Python 3.11"] --> D["Install deps (pip)"] --> E["Run: pyre check"]
  D --> F[("Repo workspace")]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Patch/replace the Pyre action dependency chain

• ➕ Keeps the workflow concise with fewer shell commands
• ➕ Potentially preserves action-specific conveniences (built-in caching/flags)
• ➖ Still relies on third-party action maintenance and transitive dependencies
• ➖ May require forking and ongoing upkeep to avoid future deprecations

2. Add pip caching (actions/cache) for pyre-check and requirements

• ➕ Speeds up CI by avoiding repeated downloads/installs
• ➕ Works well with direct Pyre execution approach
• ➖ Adds cache key management and slightly more workflow complexity
• ➖ Cache mistakes can cause confusing stale-dependency failures

Recommendation: The current approach (setup Python + pip install + pyre check) is the best fit because it removes the blocked transitive action dependency entirely and makes the CI behavior explicit and auditable. Consider adding pip caching later if runtime becomes a concern, but it’s not required to fix the failure mode described.

Files changed (1) +14 / -6

Other (1) +14 / -6

pyre.ymlReplace facebook/pyre-action with explicit Python setup and 'pyre check' +14/-6

Replace facebook/pyre-action with explicit Python setup and 'pyre check'

• Removes the 'facebook/pyre-action' step and its deprecated transitive dependencies. Adds Python 3.11 setup, installs 'pyre-check' (and requirements.txt when present), then runs 'pyre check' directly.

.github/workflows/pyre.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

1. Code scanning output removed 🐞 Bug ◔ Observability

Description

The workflow still claims Code Scanning integration and grants security-events: write, but it now
runs plain pyre check without generating/uploading SARIF, so no Pyre findings will appear in
GitHub Code Scanning.

Code

.github/workflows/pyre.yml[R53-54]

+      - name: Run Pyre
+        run: pyre check

Evidence

The workflow header explicitly states it integrates with GitHub Code Scanning and the job retains
security-events: write, but the only execution step is pyre check with no SARIF
generation/upload step present.

.github/workflows/pyre.yml[6-8]
.github/workflows/pyre.yml[30-34]
.github/workflows/pyre.yml[53-54]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow text/permissions indicate Code Scanning integration, but the job no longer produces or uploads SARIF after switching to direct `pyre check`, so Code Scanning will not receive results.

### Issue Context
This is a behavior regression from “Code Scanning workflow” semantics to a plain CI command.

### Fix Focus Areas
- .github/workflows/pyre.yml[6-8]
- .github/workflows/pyre.yml[30-34]
- .github/workflows/pyre.yml[53-54]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Pyre runs without dependencies 🐞 Bug ☼ Reliability

Description

The workflow only installs pyre-check unless a root-level requirements.txt exists, but the
repo’s Python code imports third-party modules (e.g., flask, bcrypt, jwt); this can cause Pyre
to fail with missing-import errors or produce noisy/incorrect results.

Code

.github/workflows/pyre.yml[R45-54]

+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          if [ -f requirements.txt ]; then
+            pip install -r requirements.txt
+          fi
+          pip install pyre-check
+
+      - name: Run Pyre
+        run: pyre check

Evidence

The install step installs pyre-check and only installs dependencies from requirements.txt if
present; meanwhile auth/utils.py imports multiple third-party packages that won’t be available
unless they are installed by that dependency step.

.github/workflows/pyre.yml[45-54]
auth/utils.py[1-11]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Pyre is executed after installing `pyre-check` and only *conditionally* installing `requirements.txt`. If the repo’s Python dependencies are not installed via that specific file/path, Pyre will not be able to resolve imports for modules used in the codebase.

### Issue Context
The repository contains Python files importing non-stdlib dependencies.

### Fix Focus Areas
- .github/workflows/pyre.yml[45-54]
- auth/utils.py[1-11]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Unpinned pyre-check version 🐞 Bug ⛨ Security

Description

The workflow installs pyre-check without a version pin, so CI behavior can change unexpectedly
when PyPI publishes a new release (including potential breakages or new errors) without any repo
change.

Code

.github/workflows/pyre.yml[R45-52]

+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          if [ -f requirements.txt ]; then
+            pip install -r requirements.txt
+          fi
+          pip install pyre-check
+

Evidence

The workflow uses pip install pyre-check with no ==<version> constraint, meaning the resolved
version can change over time.

.github/workflows/pyre.yml[45-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Installing an unpinned tool in CI makes checks non-deterministic and increases supply-chain risk.

### Issue Context
The workflow installs `pyre-check` directly from PyPI at runtime.

### Fix Focus Areas
- .github/workflows/pyre.yml[45-52]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Code scanning output removed 🐞 Bug ◔ Observability

The workflow still claims Code Scanning integration and grants security-events: write, but it now
runs plain pyre check without generating/uploading SARIF, so no Pyre findings will appear in
GitHub Code Scanning.

Agent Prompt

### Issue description
The workflow text/permissions indicate Code Scanning integration, but the job no longer produces or uploads SARIF after switching to direct `pyre check`, so Code Scanning will not receive results.

### Issue Context
This is a behavior regression from “Code Scanning workflow” semantics to a plain CI command.

### Fix Focus Areas
- .github/workflows/pyre.yml[6-8]
- .github/workflows/pyre.yml[30-34]
- .github/workflows/pyre.yml[53-54]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[Copilot]

Pull request overview

This PR updates the repository’s Pyre GitHub Actions workflow to avoid the deprecated transitive dependency chain introduced by facebook/pyre-action, and instead installs/runs Pyre directly within the CI job.

Changes:

• Replaced facebook/pyre-action with actions/setup-python@v5 + shell-based dependency installation.
• Runs Pyre via pyre check directly in the workflow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.