Onboard issue dedupe workflow (OpenSearch)

[peterzhuamazon]

Description

Onboard issue dedupe workflow (OpenSearch)

Related Issues

opensearch-project/opensearch-build#5912

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit a750572.

Path	Line	Severity	Description
.github/workflows/issue-dedupe.yml	22	high	External GitHub Actions workflow referenced at mutable '@main' branch instead of a pinned commit SHA: 'opensearch-project/opensearch-build/.github/workflows/issue-dedupe-detect.yml@main'. If the referenced repository is compromised or the branch is force-pushed, malicious code could execute in this repository's CI context with write access to issues and an OIDC id-token.
.github/workflows/issue-dedupe.yml	34	high	External GitHub Actions workflow referenced at mutable '@main' branch instead of a pinned commit SHA: 'opensearch-project/opensearch-build/.github/workflows/issue-dedupe-autoclose.yml@main'. Unpinned external workflow dependency is a supply chain risk per mandatory flagging rule.
.github/workflows/issue-dedupe.yml	23	medium	'id-token: write' permission is granted and the secret 'BEDROCK_ACCESS_ROLE_ISSUE_DEDUPE' (likely an AWS IAM role ARN) is forwarded to an unpinned external workflow. A compromised '@main' branch could use the OIDC token to assume the AWS role and exfiltrate credentials or access Bedrock resources.

The table above displays the top 10 most important findings.

Total: 3 | Critical: 0 | High: 2 | Medium: 1 | Low: 0

---

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

---

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 7d4676e)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 Security concerns Sensitive information exposure: The workflow passes secrets.BEDROCK_ACCESS_ROLE_ISSUE_DEDUPE to a reusable workflow hosted in an external repository (opensearch-project/opensearch-build) pinned to @main. If the external repository's main branch is compromised or changes unexpectedly, the secret could be exposed to malicious code. Pinning to a specific immutable commit SHA would mitigate this risk.

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Missing Schedule Guard The auto-close-issue job runs on schedule without a Bot-user exclusion, but more importantly the detect-issue job has no condition for the schedule event. If the cron fires, detect-issue will be skipped (correct), but it is worth verifying that the scheduled run only triggers auto-close-issue and not detect-issue unintentionally, since the if condition on detect-issue does not explicitly handle the schedule event path. if: >- (github.event_name == 'workflow_dispatch' && github.repository == 'opensearch-project/OpenSearch') || (github.event_name == 'issues' && github.event.issue.user.type != 'Bot' && github.repository == 'opensearch-project/OpenSearch') Pinned to @main Both reusable workflow references (issue-dedupe-detect.yml@main and issue-dedupe-autoclose.yml@main) are pinned to the main branch of opensearch-build. This means any breaking change pushed to that branch will immediately affect this workflow without a review cycle. Consider pinning to a specific commit SHA or a versioned tag for stability and security. uses: opensearch-project/opensearch-build/.github/workflows/issue-dedupe-detect.yml@main permissions: contents: read issues: write id-token: write secrets: BEDROCK_ACCESS_ROLE_ISSUE_DEDUPE: ${{ secrets.BEDROCK_ACCESS_ROLE_ISSUE_DEDUPE }} with: issue_number: ${{ inputs.issue_number || '' }} grace_days: ${{ vars.DUPLICATE_GRACE_DAYS || '7' }} auto-close-issue: if: github.event_name == 'schedule' && github.repository == 'opensearch-project/OpenSearch' uses: opensearch-project/opensearch-build/.github/workflows/issue-dedupe-autoclose.yml@main

[github-actions]

PR Code Suggestions ✨

Latest suggestions up to 7d4676e
Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Guard against empty issue number input The schedule event is not included in the detect-issue job condition, but the auto-close-issue job handles it. However, if a schedule event triggers the workflow, the detect-issue job will be skipped entirely, which is likely the intended behavior. But the workflow_dispatch path passes issue_number as an input — if the user provides no value, it defaults to an empty string '', which may cause the called workflow to fail or behave unexpectedly. Consider adding a validation or guard in the condition to ensure issue_number is non-empty when workflow_dispatch is used. .github/workflows/issue-dedupe.yml [17-22] if: >- (github.event_name == 'workflow_dispatch' && - github.repository == 'opensearch-project/OpenSearch') || + github.repository == 'opensearch-project/OpenSearch' && + inputs.issue_number != '') || (github.event_name == 'issues' && github.event.issue.user.type != 'Bot' && github.repository == 'opensearch-project/OpenSearch') Suggestion importance[1-10]: 5 __ Why: The suggestion is valid - passing an empty issue_number to the called workflow could cause issues. However, the required: true field on the input already enforces that workflow_dispatch must provide a value, reducing the risk. The guard adds extra safety but may be redundant.	Low
General	Ensure correct type for numeric input The grace_days input is passed as a string (e.g., '7'), but the called reusable workflow may expect an integer type. If the called workflow defines grace_days as type: number, passing a string could cause a type mismatch error. Verify the expected type in the called workflow and cast accordingly, or ensure the fallback value matches the expected type. .github/workflows/issue-dedupe.yml [40] -grace_days: ${{ vars.DUPLICATE_GRACE_DAYS || '7' }} +grace_days: ${{ fromJSON(vars.DUPLICATE_GRACE_DAYS || '7') }} Suggestion importance[1-10]: 4 __ Why: The suggestion to use fromJSON() to ensure numeric type is a valid concern if the called workflow expects type: number. However, this is speculative without seeing the called workflow's definition, and GitHub Actions often handles string-to-number coercion automatically.	Low

---

Previous suggestions

Suggestions up to commit a750572

Category	Suggestion	Impact
Possible issue	Pass triggering issue number as fallback When triggered by the issues event (a newly opened issue), inputs.issue_number will be empty and the fallback is an empty string ''. The called workflow (issue-dedupe-detect.yml) should receive the actual issue number from the event context. Consider passing github.event.issue.number as a fallback so the workflow can process the triggering issue correctly. .github/workflows/issue-dedupe.yml [30] -issue_number: ${{ inputs.issue_number || '' }} +issue_number: ${{ inputs.issue_number || github.event.issue.number }} Suggestion importance[1-10]: 8 __ Why: When the workflow is triggered by the issues event, inputs.issue_number will be empty, so the called workflow would receive an empty string instead of the actual issue number. Using github.event.issue.number as a fallback ensures the deduplication logic correctly processes the newly opened issue.	Medium
General	Clarify event handling across jobs The schedule event is not included in the detect-issue job condition, but it is also not excluded explicitly. While this may be intentional, the schedule event will silently skip the detect-issue job without any indication. Consider adding a comment or ensuring the condition is exhaustive to avoid confusion about which events trigger which jobs. .github/workflows/issue-dedupe.yml [16-21] if: >- (github.event_name == 'workflow_dispatch' && github.repository == 'opensearch-project/OpenSearch') || (github.event_name == 'issues' && github.event.issue.user.type != 'Bot' && github.repository == 'opensearch-project/OpenSearch') +# Note: 'schedule' event is intentionally handled only by auto-close-issue job Suggestion importance[1-10]: 2 __ Why: The suggestion asks to add a comment to clarify that the schedule event is intentionally handled only by auto-close-issue. While this is a valid observation, adding comments to YAML workflow files is a minor style improvement, and the improved_code only adds a comment without changing any logic.	Low

[github-actions]

Persistent review updated to latest commit 7d4676e

[cwperks]

How will this perform on this repo with 2.4k open issues?

[cwperks]

Thank you @peterzhuamazon. The prompt looks very thorough and I like that it gives the reporter the ability to refute the duplicate label. I'd like to see how this performs across a couple of repos.

I know this applies to new issues, but might be nice to apply it to the issue queue at some point in the future to help clean up this repository which currently has 2.4k open issues.

[peterzhuamazon]

Thank you @peterzhuamazon. The prompt looks very thorough and I like that it gives the reporter the ability to refute the duplicate label. I'd like to see how this performs across a couple of repos.

I know this applies to new issues, but might be nice to apply it to the issue queue at some point in the future to help clean up this repository which currently has 2.4k open issues.

Yeah Craig, I think one thing maintainer can do is to manually run the workflow through dispatch on existing issue if needed.