chore(CI): add slack notifications

[rishav-karanjit]

Issue #, if available:

Description of changes:

Adding slacking notification on daily CI failure and issue creation.

Similar PR in DB-ESDK: aws/aws-database-encryption-sdk-dynamodb#1964

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

• Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

In general, the fix is to add an explicit permissions block to the workflow (at the root level, or per job) to restrict the GITHUB_TOKEN to the minimal access necessary. Root-level permissions act as defaults for all jobs that do not override them, which is appropriate here since none of the shown jobs declare their own permissions.

The safest change without altering existing functionality is to add a root-level permissions block just after the name: Daily CI line, setting contents: read. This is the minimal common permission needed for typical CI workflows (e.g., to fetch the repo). If any of the called reusable workflows require additional scopes (such as pull-requests: write for status updates), they should define those themselves; adding contents: read at the root will not block that. The notify job appears to send a Slack message using a secret and should not need elevated GITHUB_TOKEN scopes, so the root-level contents: read is appropriate.

Concretely, in .github/workflows/daily_ci.yml, insert:

permissions:
  contents: read

between lines 2 and 4. No imports or additional definitions are required, as this is purely YAML configuration within GitHub Actions.

In general, the fix is to explicitly declare a permissions block in the workflow (at the top level, since neither job has its own) and restrict the default GITHUB_TOKEN permissions to the minimum necessary. This workflow only reacts to issues and issue_comment events and passes data plus a secret to a reusable Slack notification workflow; it doesn’t change repository contents or metadata itself. Therefore, the minimal safe default is contents: read, which allows basic read operations if needed while avoiding unnecessary write scopes.

The best fix without changing existing functionality is to add a top-level permissions block between the on: section and the jobs: section in .github/workflows/issue-notification.yml. Set contents: read as a conservative, least-privilege permission; if the reusable workflow needs something more, it can declare its own permissions in its own file, but that is outside the scope of this snippet. No imports or additional methods are needed, since this is purely a YAML configuration change.

In general, this issue is fixed by explicitly defining a permissions: block for the workflow or individual jobs, restricting the GITHUB_TOKEN to the minimal scopes needed. For an issue/comment notification workflow that only reads event payloads and sends a Slack message via a secret, no write permissions are needed; read-only access is sufficient, and often only contents: read (and optionally issues: read) is required.

The best fix here without changing functionality is to add a top-level permissions: block (applies to all jobs) near the top of .github/workflows/issue-notification.yml, underneath name: (or on:). Since the jobs simply consume github.event.issue and github.event.comment fields and delegate to a reusable Slack notification workflow, they do not perform any write operations on the repository. A safe and minimal configuration is:

permissions:
  contents: read
  issues: read

If the reusable workflow needs no GitHub API access, even issues: read may be unnecessary, but including it is harmless and explicit. No imports, methods, or additional definitions are needed; this is purely a YAML configuration change inside .github/workflows/issue-notification.yml.