Skip to content

feat: created workflow for runnig test #18

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

Closed
shivam-070208 wants to merge 6 commits into from
Closed

feat: created workflow for runnig test #18

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
0de46ac
feat: created workflow for runnig test
shivam-070208 Aug 10, 2026
7bdc130
fix : fix for bun
shivam-070208 Aug 10, 2026
ea8dd27
fix : fix for bun
shivam-070208 Aug 10, 2026
bf42787
fix: remove build
shivam-070208 Aug 10, 2026
9af0d2b
fix:bun test to bun run test
shivam-070208 Aug 10, 2026
db4f30e
fix:build step
shivam-070208 Aug 10, 2026
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
23 changes: 23 additions & 0 deletions .github/workflows/test.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
name: Test skalebot-auth on PR
Comment thread
shivam-070208 marked this conversation as resolved.
Outdated

on:
pull_request:
branches:
- master

jobs:
test:
runs-on: ubuntu-latest
Comment on lines +8 to +10

@coderabbitai coderabbitai Bot Aug 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Tracked workflow files:"
git ls-files .github/workflows || true

echo
echo ".github/workflows/test.yml:"
if [ -f .github/workflows/test.yml ]; then
  cat -n .github/workflows/test.yml
else
  echo "missing"
fi

echo
echo "GitHub Actions GITHUB_TOKEN default permission references in workflows if any:"
rg -n "permissions:|actions/checkout|pull_request|GITHUB_TOKEN|contents:" .github/workflows || true

echo
echo "Package metadata (first 30 lines package.json):"
if [ -f package.json ]; then
  sed -n '1,40p' package.json | cat -n
fi

Repository: shivam-070208/sociomate

Length of output: 2136

🌐 Web query:

GitHub Actions pull_request default GITHUB_TOKEN permissions README permissions contents read actions/checkout

💡 Result:

The GITHUB_TOKEN is an automatically generated secret used to authenticate API requests within GitHub Actions workflows [1][2]. Its default behavior and permissions are managed as follows: Default Permissions As of February 2023, new repositories and organizations (not owned by an enterprise) default to a read-only GITHUB_TOKEN [3]. Previously, the default was read/write [3][2]. This default setting can be configured in repository or organization settings, where administrators can choose between a restricted (read-only) or permissive (read/write) default [4][2]. Pull Request Behavior For workflows triggered by pull requests from forks, the GITHUB_TOKEN is always restricted to read-only access, regardless of the default permissions or any explicit permissions declared in the workflow [5][2]. This is a security design intended to protect repository secrets and state from untrusted code in fork-based pull requests [5]. Permissions and actions/checkout The actions/checkout action uses the GITHUB_TOKEN by default to fetch the repository [6][7]. To function correctly, the GITHUB_TOKEN must have read access to the repository contents [6][8]. If you explicitly define a permissions block in your workflow, you must include the following to ensure actions/checkout can retrieve the code: permissions: contents: read If you require additional functionality, such as writing data or interacting with other GitHub resources, you should explicitly define those requirements within the workflow or job level permissions block to adhere to the principle of least privilege [9][1][2]. If the GITHUB_TOKEN lacks sufficient permissions for your specific needs, you may need to use a personal access token (PAT) or a GitHub App installation token as an alternative [1][10].

Citations:

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Tracked workflow files:"
git ls-files .github/workflows || true

echo
echo ".github/workflows/test.yml:"
if [ -f .github/workflows/test.yml ]; then
  cat - n .github/workflows/test.yml
else
  echo "missing"
fi

echo
echo "GitHub Actions permission references in workflows:"
rg -n "permissions:|actions/checkout|pull_request|contents:|GITHUB_TOKEN" .github/workflows || true

echo
echo "Package metadata package.json:"
if [ -f package.json ]; then
  sed -n '1,80p' package.json | cat -n
fi

Repository: shivam-070208/sociomate

Length of output: 1015

🌐 Web query:

GitHub Actions workflows pull_request default permissions GITHUB_TOKEN read actions/checkout

💡 Result:

In GitHub Actions, the GITHUB_TOKEN is an automatically generated, short-lived token used to authenticate workflow jobs against the GitHub API [1][2]. Its permissions are critical for security and functionality [3][4]. Default Permissions The GITHUB_TOKEN default permissions are determined by settings configured at the organization or repository level [5]. Administrators can choose between two main default modes [1][6]: 1. Permissive: Grants read/write access to most scopes [5][7]. 2. Restricted: Limits access to read-only for repository contents and packages [6][5]. Crucially, when a workflow is triggered by a pull request from a public fork, GitHub automatically restricts the GITHUB_TOKEN to read-only access, regardless of the default settings, to prevent unauthorized modification or secret access [1][5][8]. Using actions/checkout The actions/checkout action requires specific permissions to function correctly because it uses the GITHUB_TOKEN to authenticate and fetch the repository code [9][7]. If you explicitly define the permissions block in your workflow, any scope you do not list is set to none [1][7]. This can cause the checkout action to fail if the necessary contents permission is omitted [7]. To ensure proper functionality, it is recommended to explicitly set the minimum required permissions at the workflow or job level [10][3]: permissions: contents: read Security Best Practices - Principle of Least Privilege: Always specify only the permissions required for your workflow tasks using the permissions key [1][10][3]. Avoid using the default permissive settings if possible [4][11]. - Pull Request Safety: Be cautious with the pull_request_target trigger, as it runs with elevated trust and access to secrets [8][4]. Do not check out untrusted fork code in a pull_request_target job without taking appropriate security precautions, such as setting persist-credentials to false [4][11]. - Token Limitations: If you need permissions exceeding those available to the GITHUB_TOKEN (e.g., accessing other repositories), use a GitHub App installation access token or a personal access token (PAT) instead [10][2][12].

Citations:

Set the workflow token to contents: read.

This PR-triggered workflow does not define permissions:, so it can inherit repository or organization defaults that are broader than the read access required for checkout, install, build, and tests. Add a workflow-level permissions block that grants only contents: read.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/test.yml around lines 8 - 10, Add a workflow-level
permissions block near the top of .github/workflows/test.yml, granting only
contents: read for the test workflow. Keep the existing jobs.test configuration
unchanged.

Source: Linters/SAST tools

steps:
- name: Checkout code
uses: actions/checkout@v4
Comment on lines +12 to +13

@coderabbitai coderabbitai Bot Aug 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== workflow head =="
sed -n '1,80p' .github/workflows/test.yml || true

echo
echo "== changed commit/stat =="
git diff --stat HEAD~1..HEAD 2>/dev/null || git status --short

echo
echo "== all workflow files =="
git ls-files '.github/workflows/*' | while read -r f; do
  echo "---- $f"
  sed -n '1,120p' "$f"
done

echo
echo "== git refs/tags/actions checkout docs in repo? =="
rg -n "persist-credentials|actions/checkout|GITHUB_TOKEN|permissions:|pull-requests" .github/package.json || true

Repository: shivam-070208/sociomate

Length of output: 1444

🌐 Web query:

actions/checkout v4 persist-credentials default true GitHub token local git config

💡 Result:

In the actions/checkout v4 GitHub Action, the persist-credentials input defaults to true [1][2]. When this setting is enabled (the default), the action configures the authentication token (or SSH key) in the local git configuration [3][4]. This allows subsequent steps in your workflow to execute authenticated git commands without needing to re-configure credentials [3][5]. Technically, this persists the GITHUB_TOKEN into the repository's local git configuration—specifically as an http.https://github.com/.extraheader value in.git/config—which enables git commands to automatically use the token [6]. During the post-job cleanup phase, the action automatically removes these credentials from the local configuration [3][4]. If you wish to prevent this behavior—for example, to reduce the security surface area if downstream steps do not require repository access—you can set persist-credentials to false [3][6]. Key points: - Default value: true [1][2]. - Effect: Configures the token/key in local git config to enable authenticated git commands [3][4]. - Cleanup: The action removes these credentials automatically after the job completes [3][4]. - Opt-out: Set persist-credentials: false in your workflow step to disable this [3][4].

Citations:

Disable checkout credential persistence.

This pull request workflow runs npm ci, npm run build, and npm test after checkout without later Git authenticated commands. Set persist-credentials: false so actions/checkout@v4 does not store GITHUB_TOKEN in the local Git config.

Proposed change 
       - name: Checkout code
         uses: actions/checkout@v4
+        with:
+          persist-credentials: false
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- name: Checkout code
uses: actions/checkout@v4
- name: Checkout code
uses: actions/checkout@v4
with:
persist-credentials: false
🧰 Tools
🪛 zizmor (1.29.0)

[warning] 12-13: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/test.yml around lines 12 - 13, Update the
actions/checkout@v4 step in the workflow to set persist-credentials to false,
preventing GITHUB_TOKEN from being stored in the local Git configuration while
leaving the existing checkout behavior unchanged.

Source: Linters/SAST tools

- name: Use Node.js 22.x
uses: actions/setup-node@v4
with:
node-version: 22.x
- name: Install dependencies
run: npm ci
- name: Build project
run: npm run build
- name: Run tests
run: npm test
Loading