Skip to content

[TT-15111] Added visor code review #408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
buger merged 1 commit into from
Sep 23, 2025
Merged

[TT-15111] Added visor code review #408

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions .github/workflows/visor.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
name: Visor

on:
pull_request:
types: [opened, synchronize]
issues:
types: [opened]
issue_comment:

Check warning on line 8 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: quality

performance Issue 

The workflow is configured to trigger on every issue comment (`issue_comment: types: [created]`). This can lead to a high number of workflow runs, consuming CI resources and potentially creating long queues for other critical jobs.
Raw output 
To conserve CI resources and reduce noise, make the trigger more specific. If the action should only run on command, add a condition to the job to check the comment body. For example: `if: startsWith(github.event.comment.body, '/visor')`.
types: [created]

Check warning on line 10 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: performance

performance Issue 

The workflow is configured to trigger on every issue comment (`issue_comment: types: [created]`). In an active repository, this can lead to excessive CI/CD resource consumption and create queues that delay other critical jobs.
Raw output 
To conserve CI resources and avoid unnecessary runs, consider making the trigger more specific. If the action is intended to be invoked by a specific command within a comment, add a condition to the job to check for that command. For example, `if: startsWith(github.event.comment.body, '/visor')`.
permissions:
contents: read
pull-requests: write
issues: write
checks: write

Check warning on line 15 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: security

security Issue 

The workflow is granted broad `write` permissions for `pull-requests`, `issues`, and `checks`. While the action may require these permissions to function, it increases the potential impact if the action is compromised. An attacker could potentially modify pull requests or issues.
Raw output 
Review the documentation for the `probelabs/visor` action to confirm if these permissions are all necessary. Adhere to the principle of least privilege by scoping down permissions to the minimum required for the action to perform its intended function.

jobs:
visor:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4

Check notice on line 22 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: performance

performance Issue 

The workflow uses `probelabs/visor@main`, which pulls the latest commit from the `main` branch of the action's repository. This can introduce instability and unpredictable performance, as a new commit in the upstream action could introduce a performance regression or breaking change without warning.
Raw output 
For predictable performance and stability, it is recommended to pin the action to a specific version, such as a release tag (e.g., `@v1`) or a full commit SHA. This ensures that the workflow's execution remains consistent and is not affected by upstream changes unless explicitly updated.

Check notice on line 22 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: quality

architecture Issue 

The workflow uses a floating action version (`probelabs/visor@main`). This can introduce unexpected breaking changes or performance regressions from the upstream repository, making the CI process less stable and harder to debug.
Raw output 
Pin the action to a specific, immutable version (a release tag like `@v1.2.3` or a full commit SHA) to ensure predictable and repeatable builds. This improves the reliability and maintainability of the workflow.

Check warning on line 22 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: style

style Issue 

The workflow uses `probelabs/visor@main`, which pins the action to the `main` branch. It is a security and stability best practice to pin actions to a specific version tag (e.g., `@v1`) or a full-length commit SHA. Using a floating reference like `main` can introduce unexpected breaking changes or vulnerabilities into your CI/CD pipeline.
Raw output 
Please check the `probelabs/visor` repository for the latest stable release tag and update the workflow to use a specific version. For example:
```yaml
      - uses: probelabs/visor@v1
```
Or pin it to a specific commit SHA for maximum security and immutability.
- uses: probelabs/visor@main

Check failure on line 23 in .github/workflows/visor.yaml

View check run for this annotation

probelabs / Visor: security

security Issue 

The workflow uses a mutable branch reference (`@main`) for the `probelabs/visor` action. This is a significant supply chain risk, as any changes pushed to the `main` branch of that repository (including malicious ones) will be automatically executed in this workflow. A compromised action could exfiltrate secrets or tamper with the build process.
Raw output 
To ensure the integrity and predictability of the workflow, pin the action to a specific, immutable commit SHA instead of a branch. This guarantees that you are always running a specific, audited version of the action.
with:
app-id: ${{ secrets.PROBE_APP_ID }}
private-key: ${{ secrets.PROBE_APP_PRIVATE_KEY }}
installation-id: ${{ secrets.PROBE_APP_INSTALLATION_ID }}
env:
GOOGLE_API_KEY: ${{ secrets.GOOGLE_API_KEY }}
Loading