ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all \u003cpre\u003e\u003ccode\u003e blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks"); } } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); } })(); (function(){ try { var __m = "github.com"; var __re = new RegExp('^' + "github\\.com" + '
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length \u003e 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

ci: add needs-attention labeling automation - #2432

Merged
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation
Jul 30, 2026
Merged

ci: add needs-attention labeling automation#2432
russellwheatley merged 3 commits into
masterfrom
ci/op-response-label-automation

Conversation

@russellwheatley

@russellwheatleyrussellwheatley commented Jul 30, 2026

Copy link
Copy Markdown
Member

Summary

  • Adds an issue_comment + issues:opened workflow, mirroring the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380:
    • On creation: newly opened issues immediately get the existing needs-attention label.
    • On an OP comment, open item (issue or PR): (re-)adds needs-attention and removes blocked: await customer response (if present).
    • On an OP comment, closed item: posts a short comment noting the item is closed and suggesting a new issue/PR if still relevant.
  • Uses only the default GITHUB_TOKEN, with permissions: {} at the workflow level and issues: write scoped per-job (no pull-requests: write — every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.
  • actions/github-script is pinned to the underlying commit SHA for v9.0.0 rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).

Notes

  • This repo already has both needs-attention and blocked: await customer response labels, so no manual label setup is needed.
  • An earlier revision of this PR also labeled newly opened PRs immediately via pull_request_target, but this repo's mandatory zizmor security scan flags pull_request_target as a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existing issue_comment flow.

Test plan

  • Merge to master, then open a new issue and confirm it's immediately labeled needs-attention.
  • Comment as the issue/PR author on an open issue/PR and confirm labels swap as expected.
  • Comment as the author on a closed issue and confirm the explanatory comment is posted.

Mirrors the workflow added to react-native-firebase, firebaseui-web,
and FirebaseUI-iOS. Two behaviors:
- New issues/PRs (including from forks, via pull_request_target) get
"needs-attention" immediately on creation.
- When the issue/PR author comments on an open item, "needs-attention"
is (re-)added and "blocked: await customer response" is removed.
Closed items get a short comment instead, pointing to a fresh
issue/PR if still relevant.
Uses only the default GITHUB_TOKEN with an explicit permissions
block, so no repository/org settings changes are required.
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's
workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it
points to, so it 422s on a plain commit lookup. zizmor's impostor-commit
check flags this as a version-comment mismatch. Repin to the underlying
commit (3a2844b7...), which still corresponds exactly to v9.0.0.
@russellwheatley
russellwheatley merged commit f4f365a into masterJul 30, 2026
18 checks passed
@russellwheatley
russellwheatley deleted the ci/op-response-label-automation branch July 30, 2026 14:44
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@russellwheatley@demolaf