Create Dynamic Template Based on PR Content

[JMielbrecht]

close #87

PR Author's Note

I've added a GitHub action to automatically label the PR based on the file types modified and edited the PR template for neatness and simplicity by eliminating checkboxes and organizing instructions for content/code contributions under the relevant dropdown. Note: The PR template below is outdated and the changes I've made to the template will only be visible once merged into main. In the meantime, here's some screenshots of what the checklist would be:

Checklist

• Philosophical or literary contribution (docs). Leave unchecked for
  code contribution.

  • IMPLIED CONSENT By opening this pull request and contributing
    philosophical or literary content, I accept that my writing is submitted
    under the
    ATTRIBUTION-NONCOMMERCIAL-SHAREALIKE 4.0 INTERNATIONAL,
    which:

    • Prohibits commercial reuse of the content.
    • Allows sharing, remixing, and building upon the material as long as
      attribution is given.

    I understand that my writing may be modified, remixed, and built upon by
    others within the systemphil/sphil or sPhil project, in accordance
    with the license terms, indefinitely. See
    legal code.

  • REQUIRED I have followed the
    formatting guidelines
    and verified there are no formatting bugs.
    Try markdown preview here.

  • REQUIRED I have followed the
    Chicago author-date style.

  • REQUIRED I have added or verified metadata title, description, and
    contributors at the very top of the file followed by a ## title
    heading. Additionally, I have ensured isArticle is set to true.
    Example:

    ---
    title: The Immediate Difference Between Pure Being and Pure Nothing
    description:
        Learn about the difference between being and nothing in Hegel's
        Science of Logic.
    isArticle: true
    authors: Jerry Maguire (2024)
    editors: Steve Stevenson (2023), Karen Hansen (2022)
    contributors:
    ---
    
    ## My Article Title

    Further information

    I have signed the document with my name/username under either as
    Authors, Editors or Contributors.

    Use Authors if you have created and substantially added content.
    Use Editor if you have made substantial edits or review.
    Use Contributor if you have made minor edits, reviews or
    contributions.
    If you've done multiple, pick the most weighted: Author > Editor >
    Contributor.
    If you prefer to remain anonymous, that's fine too, but note that a
    record of your contributions based on your GitHub username will exist
    here in the codebase.

  • REQUIRED I have ensured that the
    project's central bibliography
    contains the necessary bibliographical details for the citations I have
    used.

  • Optional My article is a stub or I want to actively encourage
    contribution, I've added the Stub component to the bottom of my content
    or where relevant:

    import Stub from "@/components/Stub";
    
    <Stub />;

• If Docs contribution is unchecked: Code contribution
  (Apache version 2 license)

  All code apart of what is inside src/pages/** (excluding
  /contributing/**, _app.mdx, _document.tsx, _meta.json,
  acknowledgements.mdx, index.mdx, privacy.mdx, team.mdx, terms.mdx)
  is subject to Apache version 2 license. Basically, anything outside of
  content, literature, philosophy.

[Firgrep]

The PR template is lookig good! Some minor adjustments to that.

There are some bigger questions regarding the workflow. I reckon it work by granting permissions within the PR.

The thing is, this is very hard to test without merging it in. Is it possible to test in the fork? Otherwise, would you consider setting up a quick dummy repo with a few files and folders to just test this workflow?

I got this thing autogenerated, could it be helpful? (see details below)

name: PR File Change Labeler

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  label-pr:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Label PR based on changed files
        uses: actions/github-script@v7
        with:
          script: |
            const { data: files } = await github.rest.pulls.listFiles({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: context.issue.number
            });
            
            let hasContentChanges = false;
            let hasCodeChanges = false;
            
            // Check each changed file
            files.forEach(file => {
              if (file.filename.endsWith('.mdx')) {
                hasContentChanges = true;
              } else {
                hasCodeChanges = true;
              }
            });
            
            // Get current labels
            const { data: currentLabels } = await github.rest.issues.listLabelsOnIssue({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number
            });
            
            const currentLabelNames = currentLabels.map(label => label.name);
            
            // Add labels if they don't already exist
            if (hasContentChanges && !currentLabelNames.includes('CONTENT')) {
              await github.rest.issues.addLabels({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                labels: ['CONTENT']
              });
            }
            
            if (hasCodeChanges && !currentLabelNames.includes('CODE')) {
              await github.rest.issues.addLabels({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: context.issue.number,
                labels: ['CODE']
              });
            }

[JMielbrecht]

The PR template is lookig good! Some minor adjustments to that.

There are some bigger questions regarding the workflow. I reckon it work by granting permissions within the PR.

The thing is, this is very hard to test without merging it in. Is it possible to test in the fork? Otherwise, would you consider setting up a quick dummy repo with a few files and folders to just test this workflow?

If you go to my forked repository, I've opened a PR running a very similar script (although this one is based off of file paths and not file extensions) that works perfectly. You can check out that PR here for reference: JMielbrecht#3

I'm not sure what you mean by “granting permissions within the PR”. If someone with admin permissions could create a personal access token with write permissions to PR’s, and add this token as a secret to the sPhil GitHub organization, I think this would solve the 403 error I’m getting in the workflow logs within this PR. I’m basing this off of the fact that the workflow in my aforementioned fork PR works perfectly fine, presumably because it’s my PR and I have admin access for that fork.

Once I get a token that has more expansive permissions, then I can create & modify some files in this branch to test its functionality. (I'll have to remember to revert these changes before merging, of course.)

I'll address your other feedback later tonight when I get off work. Thanks for the feedback!