Determine How to Send Notifications to a Slack Channel for the List of PRs in the LSP4IJ Repo Based on Cron Jobs

[vaisakhkannan]

Resource for Slack/GitHub integration: https://github.com/integrations/slack This issue is specifically the second work item of issue #802

[vaisakhkannan]

The approach taken for the solution:

Step 1: Create a Slack App

Go to the Slack API and create a new app for your workspace. Navigate to the "Incoming Webhooks" section and activate it. Add the app to your desired channel to obtain the Webhook URL. Step 2: Create a GitHub Actions Workflow

Create a Workflow File: In your GitHub repository, create a new file under the .github/workflows/ directory, e.g., .github/workflows/slack-notifications.yml. Step 3: Use API calls to fetch information about new pull requests in the repository and send notifications to Slack.

Step 4: Add Slack Webhook Secret

In your GitHub repository, go to "Settings" -> "Secrets" and add a secret named SLACK_WEBHOOK_URL with the value of the Slack Webhook URL. Step 5: Customize the GitHub API request in the workflow file based on our needs.

Step 6: Commit and Push Changes

Commit the new files (the workflow file) and push them to the GitHub repository. Step 7: Verify Workflow Execution

After pushing the changes, check the Actions tab in our GitHub repository to verify that the workflow runs successfully.

[vaisakhkannan]

The solution used for this issue is a GitHub Actions workflow scheduled to run at 07:30 UTC (1:00 PM IST) on weekdays. It performs the following tasks

1. Checkout Repository: Ensures the repository is accessible.
2. Fetch Recent Cache: Installs the gh-actions-cache extension, retrieves the latest cache key, and sets it as an environment variable.
3. Restore Cache: Restores the cache using the fetched cache key.
4. Check Cache Hit: Verifies if the cache was restored successfully.
5. Ensure Cache Directory Exists: Creates a cache directory if it doesn't exist.
6. Check Cache Restoration: Confirms if the cache restoration was successful by checking for a specific file (cache/notified_prs.json)
7. Fetch Open Pull Requests: Retrieves details of open pull requests based on API calls ( https://api.github.com/repos/redhat-developer/lsp4ij/pulls) from the repository, compares them with previously cached pull requests (The list of previously cached Pull Requests will be retrieved from the cache/notified_prs.json file, which is obtained using the restore cache key.) , and determines if any are new or updated
8. Fetch Closed Pull Requests: Retrieves pull requests closed in the last 24 hours (We designed the cron jobs to run daily. If we plan to schedule cron jobs based on other intervals, we need to consider fetching the closed PR list within that specific time interval. For example, if we set cron jobs to trigger every 48 hours, then we provide the code to fetch closed PRs from the last 24 hours only. The issue arises because we won't capture PRs that were opened and closed within the first 24 hours of the 48-hour interval before the previous cron job ran.)
9. Send Slack Notifications: Sends notifications to a Slack channel if there are new/updated open pull requests or recently closed pull requests.
10. Verify Cache Save: Checks and lists the contents of the cache directory.
( Verifying the cache that needs to be stored in the current run based on the current run's cache key and the list of newly notified pull requests—> This list will no longer include closed PRs.)
11. Save Cache: Saves the current state of notified pull requests to the cache using current run cache key
12. Cleanup Old Cache: Deleting the restored cache key to maintain cache efficiency. There is an additional condition [ $mostRecentCacheKey == Linux-pr-cache-* ] that checks if the cache key starts with 'Linux-pr-cache-', ensuring the correct cache key is used for deletion. This prevents conflicts when other cache keys are used for different jobs in the future.

NOTE:secrets.GITHUB_TOKENis automatically provided by GitHub Actions for each workflow run, so there is no need to manually create or manage this token. Additionally, we are specifyingactions: write permission in the YAML file at the end, which enables the deletion of the restored cache key.

 permissions:
      actions: write

Otherwise, we need to grant read and write permissions in the repository settings under "Settings" > "Actions" > "General" > "Workflow permissions." Alternatively, a Personal Access Token (PAT) with repo andworkflow access needs to be created. This PAT must be added as a secret in the repository settings, and that secret can be used to delete the cache key by specifying GH_TOKEN: ${{ secrets.PAT }}, where PAT is the name of the secret added in the repository settings.

[TrevCraw]

Fetch Closed Pull Requests: Retrieves pull requests closed in the last 24 hours (We designed the cron jobs to run daily. If we plan to schedule cron jobs based on other intervals, we need to consider fetching the closed PR list within that specific time interval. For example, if we set cron jobs to trigger every 48 hours, then we provide the code to fetch closed PRs from the last 24 hours only. The issue arises because we won't capture PRs that were opened and closed within the first 24 hours of the 48-hour interval before the previous cron job ran.)

Is there a way to update the code so that we can retrieve the closed pull requests since the last cron job ran? That way, we can avoid this issue if we change the cron job interval.

[vaisakhkannan]

@TrevCraw , I made the change in the code, so now we can retrieve the closed pull requests since the last cron job ran.