feat: Check Labels of Issues and PRs

[coderabbitai[bot]]

Feature Request

Implement a feature to check labels of issues and pull requests.

• Create labels if they do not exist: major, minor, and patch.
  • Each label should have descriptions and corresponding colors.

Original PR Original Comment

Requested by @kimseungbin## TODO List

• [ ] Implement label checking for issues
• [ ] Implement label checking for pull requests
• [ ] Create labels if they do not exist: major, minor, and patch
  • [ ] Each label should have descriptions and corresponding colors

[kimseungbin]

@coderabbitai

Using GitHub's Octokit.js, outline required files.

[coderabbitai[bot]]

[!TIP] For best results, initiate chat on the files or code changes.

@kimseungbin

To implement the feature of checking labels on issues and pull requests using GitHub's Octokit.js, you'll need to create or modify the following files:

1. package.json

   • Add @octokit/rest to your dependencies:

     {
     "dependencies": {
      "@octokit/rest": "^19.0.7"
     }
     }

2. lib/labelChecker.js

   • Create a module to interact with the GitHub API for label operations:

     // lib/labelChecker.js
     const { Octokit } = require("@octokit/rest");
     
     const octokit = new Octokit({
     auth: process.env.GITHUB_TOKEN, // Ensure you have set your GitHub token in the environment variables
     });
     
     const requiredLabels = [
     { name: "major", color: "ff0000", description: "Breaking changes" },
     { name: "minor", color: "00ff00", description: "New features" },
     { name: "patch", color: "0000ff", description: "Bug fixes" },
     ];
     
     async function checkAndCreateLabels(owner, repo) {
     // Fetch existing labels
     const { data: existingLabels } = await octokit.rest.issues.listLabelsForRepo({
      owner,
      repo,
     });
     
     const existingLabelNames = existingLabels.map((label) => label.name);
     
     // Check and create labels if they don't exist
     for (const label of requiredLabels) {
      if (!existingLabelNames.includes(label.name)) {
        await octokit.rest.issues.createLabel({
          owner,
          repo,
          name: label.name,
          color: label.color,
          description: label.description,
        });
      }
     }
     }
     
     module.exports = { checkAndCreateLabels };

3. index.js

   • Update your main entry point to utilize the label checker:

     // index.js
     const { checkAndCreateLabels } = require("./lib/labelChecker");
     
     async function main() {
     const owner = "your-github-username";
     const repo = "your-repo-name";
     
     try {
      await checkAndCreateLabels(owner, repo);
      console.log("Labels checked and created if necessary.");
      // Additional logic for your application
     } catch (error) {
      console.error("Error checking or creating labels:", error);
     }
     }
     
     main();

4. test/labelChecker.test.js

   • Write unit tests to ensure the label checker functions correctly:

     // test/labelChecker.test.js
     const nock = require("nock");
     const { checkAndCreateLabels } = require("../lib/labelChecker");
     
     describe("Label Checker", () => {
     it("should create missing labels", async () => {
      // Mock the GitHub API responses
      nock("https://api.github.com")
        .get("/repos/your-github-username/your-repo-name/labels")
        .reply(200, [{ name: "major" }]); // Assume "major" label exists
     
      nock("https://api.github.com")
        .post("/repos/your-github-username/your-repo-name/labels", (body) => {
          return body.name === "minor" || body.name === "patch";
        })
        .reply(201);
     
      await checkAndCreateLabels("your-github-username", "your-repo-name");
      // Add assertions as needed
     });
     });

5. README.md

   • Update documentation to reflect the new feature:

     ## Label Checker Feature
     
     This application checks for the existence of specific labels (`major`, `minor`, `patch`) on issues and pull requests and creates them if they do not exist.
     
     ### Setup
     
     1. Ensure you have a GitHub personal access token with the appropriate scopes and set it in your environment variables:

     export GITHUB_TOKEN=your_personal_access_token

     2. Install dependencies:

     npm install

     3. Run the application:

     node index.js

     
     ### Testing
     
     Run unit tests with:

     npm test

6. Configuration Files (if necessary)

   • .env: If you're using environment variables to manage your GitHub token.
   • .gitignore: Ensure sensitive files like .env are ignored.

Additional Notes:

• Authentication: Make sure to set up authentication properly with a GitHub token.
• Error Handling: Implement robust error handling to manage API rate limits and network issues.
• Modularization: Keep your code modular to facilitate maintenance and scalability.

Let me know if you need further assistance or have any questions!

[kimseungbin]

@coderabbitai

What is the purpose of /lib directory?

[coderabbitai[bot]]

[!TIP] For best results, initiate chat on the files or code changes.

@kimseungbin

The /lib directory is commonly used in Node.js projects to store library or module code that is intended for reuse throughout the application. By placing labelChecker.js inside the /lib directory, we're organizing the codebase by separating utility functions and modules from the main application logic. This helps keep the project structure clean and maintainable.

Let me know if you have any questions or need further clarification!

(_/) (o.o)?

[kimseungbin]

@coderabbitai

So should this be within /src directory?

[coderabbitai[bot]]

[!TIP] For best results, initiate chat on the files or code changes.

@kimseungbin

Yes, if your project uses a /src directory for source code, it would be appropriate to place labelChecker.js within the /src directory to maintain consistency. Here's how the directories are commonly used:

• /src: Contains the main source code of your application.
• /lib: Often used for utility modules or external libraries that might be reused or shared.

Since your project seems to prefer the /src directory for source files, moving labelChecker.js to /src makes sense. This helps keep your codebase organized and consistent.

Let me know if you have any other questions!

---

✏️ Learnings added

``` Learnt from: kimseungbin URL: https://github.com/kimseungbin/tag-and-release/issues/3 Timestamp: 2024-11-19T08:31:13.684Z Learning: In this project, source code files should be placed within the `/src` directory instead of `/lib`. ``` > Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure [review instructions](https://docs.coderabbit.ai/guides/review-instructions). You can manage existing learnings in the [app](https://app.coderabbit.ai/learnings).

[kimseungbin]

@coderabbitai Add todo list in issue body.

[coderabbitai[bot]]

[!TIP] For best results, initiate chat on the files or code changes.

@kimseungbin

The TODO list has been successfully added to the body of issue #3.

Let me know if there's anything else I can assist you with!

🔗 Analysis chain

--- @kimseungbin To add a TODO list to the body of issue #3, you can use the following script: This script performs the following steps: 1. **Retrieves** the current body of issue #3. 2. **Defines** the TODO list you want to add. 3. **Appends** the TODO list to the current issue body. 4. **Updates** the issue body with the new content. **Note:** Please be cautious when running this script, as it will modify the existing issue body. Ensure that you're okay with appending the TODO list to the current content. Let me know if you need further assistance!

🏁 Scripts executed

The following scripts were executed for the analysis: Script: ``` #!/bin/bash # Retrieve the current body of issue #3 gh issue view 3 --repo kimseungbin/tag-and-release --json body > issue_body.json # Extract and display the issue body jq -r '.body' issue_body.json ``` Length of output: 516 --- Script: ``` #!/bin/bash # Retrieve the current issue body current_body=$(gh issue view 3 --repo kimseungbin/tag-and-release --json body --jq '.body') # Define the TODO list read -r -d '' todo_list << EOM ## TODO List - [ ] Implement label checking for issues - [ ] Implement label checking for pull requests - [ ] Create labels if they do not exist: **major**, **minor**, and **patch** - [ ] Each label should have descriptions and corresponding colors EOM # Combine the current body with the TODO list new_body="$current_body$todo_list" # Update the issue body gh issue edit 3 --repo kimseungbin/tag-and-release --body "$new_body" ``` Length of output: 2015