Skip to content

feat: Add first interaction workflow for new contributors #147

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

Open
yogeshkumawat2027 wants to merge 2 commits into
base: main
Choose a base branch
from
Open

feat: Add first interaction workflow for new contributors #147

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4d9ae96
fix: correct SQL syntax errors in schema.sql
yogeshkumawat2027 Dec 14, 2025
7065026
feat: add first interaction workflow for new contributors
yogeshkumawat2027 Dec 14, 2025
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
42 changes: 42 additions & 0 deletions .github/workflows/first-interaction.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
name: First Interaction

on:
issues:
types: [opened]
pull_request_target:
types: [opened]

jobs:
greeting:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/first-interaction@v1
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
issue-message: |
👋 **Welcome to NeuroTrack!**

Thank you for opening your first issue! We're excited to have you as part of our community. 🎉

A maintainer will review your issue soon. In the meantime, please make sure you've provided all the necessary details to help us understand and address the issue effectively.

If you'd like to contribute code, check out our [Contributing Guidelines](../CONTRIBUTING.md) to get started.

Happy coding! 🚀
pr-message: |
🎉 **Congratulations on your first Pull Request!**

Thank you for contributing to NeuroTrack! We really appreciate your effort and time. 💙

Our team will review your PR as soon as possible. Here are some things that might help:

- Make sure all tests pass ✅
- Ensure your code follows our coding standards 📝
- Check that your PR description clearly explains what changes you've made and why 📋

If you haven't already, please take a look at our [Contributing Guidelines](../CONTRIBUTING.md).

Thanks again for your contribution! 🙌
Comment on lines +1 to +42
Copy link

@coderabbitai coderabbitai bot Dec 14, 2025

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

GitHub Actions pull_request_target security best practices write permissions minimal permissions

💡 Result:

Short checklist — secure use of pull_request_target + minimal write permissions

  • Prefer pull_request (unprivileged) for building/running untrusted code; use pull_request_target only for metadata ops (labels/comments) that must run with repo context. If you must build PR code, run it in an unprivileged job and then use workflow_run to perform privileged updates. [1][2][3]

  • Set least-privilege GITHUB_TOKEN explicitly with the permissions key (at workflow or job level). Grant only the specific scopes needed (for example contents: read; issues: write only if commenting; pull-requests: write only if updating PRs). Avoid leaving defaults. Example:
    permissions:
    contents: read
    issues: none
    pull-requests: write
    [4][5]

  • Never checkout or execute untrusted fork code in a pull_request_target job. actions/checkout of the PR head in a privileged context is a common pwn-request vector. If you must access PR HEAD, do so in an unprivileged pull_request job. [2][6]

  • Avoid secrets in runs triggered by external contributors. pull_request_target has access to repository secrets — do not expose secrets to workflows that process untrusted input. Use OIDC where possible instead of long-lived secrets. [2][5]

  • Use a two-stage pattern for PR checks:

    1. pull_request — run tests/lints on untrusted code (no secrets, read-only token).
    2. workflow_run (or a maintainer-approved manual job) — with write permissions/secrets, consume artifacts from step (no checkout of PR HEAD). This prevents executing untrusted code with secrets. [3][8]

  • Scope third-party actions and reusable workflows: pin to full commit SHAs, review action code, and minimize the actions permission (actions: none) unless required. [5]

  • Use labels/“safe to test” gating and manual approvals for runs that need elevated privileges. Combine repository branch protection and required reviewers to prevent automatic merges from untrusted workflows. [6][8]

  • Monitor and iterate: use tools (GitHub Security Lab / actions-permissions Monitor & Advisor) or instrumented runs to observe the real permissions your workflows use and then tighten permissions to the minimal set. [3]

Quick examples / references

  • GitHub Security Lab explanation of pull_request_target risks and workflow_run pattern. [3]
  • GitHub docs: setting GITHUB_TOKEN permissions and security-hardening guide (permissions, OIDC, disabling Actions auto-PRs). [4][5]
  • CodeQL / security guidance: “avoid checkout of untrusted code in privileged context.” [6]

Sources
[1] GitHub Blog — Four tips to keep your GitHub Actions workflows secure.
[2] GitHub Security Lab — Keeping your GitHub Actions and workflows secure: Preventing pwn requests.
[3] GitHubSecurityLab/actions-permissions (Monitor & Advisor) repo.
[4] GitHub Docs — Assigning permissions to jobs / Use GITHUB_TOKEN.
[5] GitHub Docs — Security hardening for GitHub Actions (OIDC, pin actions, disable automation).
[6] CodeQL docs — Checkout of untrusted code in a privileged context.

(If you want, I can convert this into a ready-to-drop workflow template that enforces minimal permissions and the two-stage pattern.)

🌐 Web query:

GitHub Actions first-interaction latest version release pinning commit SHA vs tag

💡 Result:

Short answer

  • actions/first-interaction latest release series is v3 (latest reported v3.1.0). Pin by full commit SHA for strongest safety; tags (v3, v3.1.0) are convenient but mutable. [1][2][3]

Why

  • Tags and branches are mutable: a tag can be moved/rewritten by the repo owner, which can cause workflows that use tags to start running different code later. Pinning to a full 40‑char commit SHA is immutable and guarantees exactly which code will run. [2][4]

Practical guidance

  • To use the published tag (convenient, gets updates): uses: actions/first-interaction@v3.1.0.
  • To pin to a specific commit (recommended for security/auditing): uses: actions/first-interaction@[full-commit-sha] # e.g. actions/first-interaction@f43a0e5... (add a comment with the tag/version for readability). [2][4]
  • Consider tooling to automate safe updates (Dependabot, actions-up, gha-pinner, pinsha) and enable organizational SHA‑pin enforcement / immutable releases where available. [5][6][1]

Sources

  1. Release listing for actions/first-interaction (v3.1.0). [NewReleases / GitHub]. [1]
  2. GitHub Actions pinning best practice: pin to full commit SHA (explanation + examples). [JonasBN / til; security guides]. [2]
  3. GitHub changelog: enforce SHA pinning and immutable releases roadmap. [GitHub Changelog]. [3]
  4. Real-world issue where a tag was changed after release (shows risk of tag mutability). [actions/checkout issue]. [4]
  5. actions-up (auto-update + SHA pinning tool). [5]
  6. gha-pinner / pinsha tools and examples for resolving tags to SHAs. [6]

🌐 Web query:

relative links GitHub issue PR comments resolve ../CONTRIBUTING.md

💡 Result:

Short answer: GitHub's relative-link resolution works when rendering Markdown files in the repo (README, docs, etc.) but is unreliable in PR/issue comments and some template contexts — so ../CONTRIBUTING.md in an issue/PR comment will usually not resolve to the repo file you expect. Use an absolute GitHub URL or a repo-root absolute path to the blob (or the special owner/repo/blob/branch path) instead.

Why and what to do:

  • GitHub Docs: relative links (./, ../ and starting with /) are supported and are resolved relative to the file when GitHub renders repository Markdown files. [1]
  • In comments, templates and some UI contexts the renderer rewrites relative paths based on the current page (compare/PR, wiki, etc.), so ../ or ./ links can point to compare/ or other pages rather than the repo file. Community/StackOverflow reports show PULL_REQUEST_TEMPLATE and comment contexts break expected relative-link behavior. [2][3]

Practical fixes:

  • Use the canonical blob URL for the file: https://github.com/OWNER/REPO/blob/BRANCH/PATH/TO/CONTRIBUTING.md (paste the full URL). This always works in comments.
  • Or use repo-root absolute path form when appropriate: /OWNER/REPO/blob/BRANCH/.github/CONTRIBUTING.md (or just /OWNER/REPO/.github/CONTRIBUTING.md if you want the browser to resolve it) — but full blob URLs are safest.
  • If you want branch-stable permalinks, link to the file with the branch name (or use the file’s permalink via the GitHub UI). [1][4]

Sources:

  1. GitHub — Basic writing and formatting syntax (relative links support). [1]
  2. Stack Overflow — relative links in PULL_REQUEST_TEMPLATE.md / PR view problems. [2]
  3. GitHub Community / discussions reporting wiki/comment preview vs saved-page relative-path issues. [3]
  4. GitHub Docs — Creating permanent links to files/code (use permalink/blob). [4]

If you want, tell me the repo and path and I’ll produce the exact safe URL you should paste into your comment.

Set minimal explicit permissions—grant only issues: write for issues and only pull-requests: write for PRs, not both.
You're using pull_request_target correctly (no checkout), but GitHub recommends scoping permissions to the narrowest set needed. Currently both issues: write and pull-requests: write are granted together. Add a permissions: key to each event or split jobs if you prefer, but explicit scoping is the priority—splitting alone without scoped permissions does not reduce the attack surface.

Upgrade and pin actions/first-interaction to its commit SHA.
The workflow uses @v1 (outdated; latest is v3.1.0). Pin to a full commit SHA instead of a tag, since tags are mutable and can move. For example: uses: actions/first-interaction@[commit-sha] with a comment noting the release version for future reference. This hardens the workflow against supply-chain drift.

Use absolute repository URLs for CONTRIBUTING.md instead of relative paths.
Relative paths like ../CONTRIBUTING.md do not resolve correctly in issue/PR comment bodies. Replace with the full GitHub blob URL: https://github.com/[OWNER]/[REPO]/blob/[BRANCH]/CONTRIBUTING.md.

🤖 Prompt for AI Agents 
.github/workflows/first-interaction.yml lines 1-42: the workflow grants both
issues: write and pull-requests: write globally, uses an unpinned tag for
actions/first-interaction, and uses relative links that won't render in
comments; update the workflow to scope permissions narrowly (give only issues:
write for the issues trigger and only pull-requests: write for the
pull_request_target trigger — either by adding a permissions: block per job/step
or splitting into separate jobs with scoped permissions), replace uses:
actions/first-interaction@v1 with the action pinned to a specific commit SHA and
add a short comment noting the release version, and change relative
CONTRIBUTING.md links to the absolute GitHub blob URL
(https://github.com/OWNER/REPO/blob/BRANCH/CONTRIBUTING.md) so links resolve
correctly in comments.

12 changes: 6 additions & 6 deletions supabase/schemas/schema.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ CREATE TABLE therapist (
regulatory_body TEXT,
start_availability_time TEXT,
end_availability_time TEXT,
license_number TEXT,
license_number TEXT
);

-- Create the package table
Expand Down Expand Up @@ -120,7 +120,7 @@ CREATE TABLE observation_master (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
created_at TIMESTAMPTZ DEFAULT NOW(),
observation_text TEXT NOT NULL,
applicable_therapies UUID[] NOT NULL,
applicable_therapies UUID[] NOT NULL
);

-- Regressions Master Table
Expand All @@ -136,7 +136,7 @@ CREATE TABLE activity_master (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
created_at TIMESTAMPTZ DEFAULT NOW(),
activity_text TEXT NOT NULL,
applicable_therapies UUID[] NOT NULL,
applicable_therapies UUID[] NOT NULL
);

-- Daily Activities Table
Expand All @@ -150,15 +150,15 @@ CREATE TABLE daily_activities (
patient_id UUID REFERENCES patient(id),
start_time TIMESTAMPTZ,
end_time TIMESTAMPTZ,
days_of_week INT2[],
days_of_week INT2[]
);

CREATE TABLE daily_activity_logs (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
activity_id UUID REFERENCES daily_activities(id) ON DELETE CASCADE,
date TIMESTAMPTZ NOT NULL,
activity_items JSONB NOT NULL
patient_id UUID REFERENCES patient(id) ON DELETE CASCADE,
activity_items JSONB NOT NULL,
patient_id UUID REFERENCES patient(id) ON DELETE CASCADE
);

-- Indexes on foreign keys for better performance
Expand Down