feat: Add first interaction workflow for new contributors

[yogeshkumawat2027]

✨ Feature

Added GitHub Actions workflow to welcome first-time contributors with friendly messages.

📝 Changes Made

• Created .github/workflows/first-interaction.yml
• Configured welcome messages for first issues and PRs
• Added proper permissions for GitHub token

🎯 Benefits

• Makes new contributors feel welcomed and valued 🎉
• Provides guidance on contributing guidelines
• Encourages community involvement
• Automated and requires no manual intervention

✅ Testing

• Workflow will trigger automatically when a new contributor opens their first issue or PR
• Uses GitHub's official actions/first-interaction@v1 action

Summary by CodeRabbit

• Chores
  • Added automated welcome messages for new contributors submitting issues and pull requests, with helpful guidelines and resources.
  • Improved database schema formatting for better readability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This change introduces a GitHub Actions workflow for automated first-interaction greetings on new issues and pull requests, and applies formatting adjustments (commas and line breaks) to a database schema file without altering its structure or constraints.

Changes

Cohort / File(s)	Summary
GitHub Actions Workflow .github/workflows/first-interaction.yml	New workflow triggered on issue and PR creation, uses actions/first-interaction@v1 to post welcome messages directing users to contributing guidelines
Database Schema Formatting supabase/schemas/schema.sql	Whitespace and comma formatting adjustments in table definitions with no changes to column types, constraints, or relationships

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• GitHub Actions workflow: Straightforward configuration using standard GitHub Action with templated message content
• SQL schema: Pure formatting changes with no semantic alterations; safe cosmetic edits

Poem

🐰 A workflow so neat, a greeting so sweet,

For newcomers joining, we bid them entreat,

And schemas? Just tidied, commas aligned,

No logic disrupted—formatting refined! 🌟

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding a GitHub Actions workflow to welcome first-time contributors, which aligns perfectly with the primary file addition (.github/workflows/first-interaction.yml) and PR objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

supabase/schemas/schema.sql (1)

143-154: Consider a CHECK constraint for daily_activities.days_of_week values.
If the app expects 0–6 (or 1–7), enforcing that in DB can prevent bad data from silently creeping in.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5a2d6eb and 7065026.

📒 Files selected for processing (2)

• .github/workflows/first-interaction.yml (1 hunks)
• supabase/schemas/schema.sql (4 hunks)

🔇 Additional comments (4)

supabase/schemas/schema.sql (4)

34-37: If license_number is new, treat as a real migration (not formatting-only).
Adding a column may require backfill, validation, and client updates; consider NOT NULL/UNIQUE (or at least documenting expected format) if this is an identifier you’ll rely on.

---

121-124: No concerns with observation_master.applicable_therapies reflow.
Reads as formatting-only.

---

137-140: No concerns with activity_master.applicable_therapies reflow.
Reads as formatting-only.

---

156-162: Good fix: daily_activity_logs comma + clearer column separation.
This looks like a safe formatting/syntax improvement (and avoids accidental SQL errors around column lists).

[coderabbitai]

⚠️ 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.