Skip to content

chore: update fullsend per-repo installation - #943

Closed
ggallen wants to merge 1 commit into
mainfrom
fullsend/scaffold-install
Closed

chore: update fullsend per-repo installation#943
ggallen wants to merge 1 commit into
mainfrom
fullsend/scaffold-install

Conversation

@ggallen

@ggallen ggallen commented Aug 22, 2026

Copy link
Copy Markdown
Member

The default branch (main) has branch protection rules that prevent direct pushes.

Merge this PR to deliver the scaffold files.

@ggallen
ggallen requested a review from a team as a code owner August 22, 2026 19:31
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Pin fullsend per-repo workflows and add prioritize scaffold

⚙️ Configuration changes ✨ Enhancement 🕐 10-20 Minutes

Grey Divider

AI Description

• Pin fullsend reusable workflows to a specific commit for deterministic runs.
• Add required per-repo inputs/vars (including GCP project_number) for fullsend jobs.
• Update fullsend per-repo config allowlists and add the managed Prioritize workflow.
Diagram

graph TD
  A(["GitHub event"]) --> B["fullsend workflow"] --> C{{"reusable-dispatch@sha"}}
  A --> D["prioritize workflow"] --> E{{"reusable-prioritize@sha"}}
  F[".fullsend/config.yaml"] --> B --> H[("GCP via WIF")]
  F --> D
  G(["Repo vars/secrets"]) --> B
  G --> D
  subgraph Legend
    direction LR
    _evt(["Trigger"]) ~~~ _wf["Repo workflow"] ~~~ _ext{{"External reusable"}} ~~~ _sec(["Vars/Secrets"]) ~~~ _cloud[("Cloud")]
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Track reusable workflows on main
  • ➕ Always picks up upstream fixes without manual updates
  • ➕ No need to manage version bumps
  • ➖ Non-deterministic CI behavior; upstream changes can break this repo unexpectedly
  • ➖ Harder to audit exactly what ran for a given build
2. Pin to a release tag (e.g., vX.Y.Z) instead of a commit SHA
  • ➕ Deterministic like a SHA, but more human-readable
  • ➕ Easier coordinated upgrades across repos
  • ➖ Requires upstream to publish and maintain tags/releases reliably
  • ➖ Still needs periodic upgrade work in downstream repos
3. Centralize shared vars in org/environment instead of per-repo vars
  • ➕ Less per-repo configuration drift
  • ➕ Simplifies onboarding many repos
  • ➖ May not fit if project_number/region differ per repo
  • ➖ Increases blast radius if shared values are changed incorrectly

Recommendation: Pinning reusable workflows to a commit SHA is a solid choice for reproducibility and auditability, especially for automation that can write issues/PRs. If upstream provides stable releases, consider pinning to a version tag for readability while keeping deterministic behavior; otherwise keep SHA pinning with a periodic upgrade process.

Files changed (3) +52 / -8

Other (3) +52 / -8
config.yamlUpdate per-repo fullsend config roles and allowlists +4/-7

Update per-repo fullsend config roles and allowlists

• Adds the "fix" role and adjusts allowed remote resources to the fullsend-ai repositories. Updates issue-creation target allowlist to explicitly include fullsend-ai/agents alongside fullsend-ai/fullsend, and removes older scaffold entries no longer needed in this per-repo config.

.fullsend/config.yaml

fullsend.yamlPin reusable-dispatch workflow and pass GCP project_number +2/-1

Pin reusable-dispatch workflow and pass GCP project_number

• Switches the reusable workflow reference from @main to a specific commit SHA for deterministic execution. Adds project_number to the inputs passed to the reusable workflow, sourced from FULLSEND_PROJECT_NUMBER repo variable.

.github/workflows/fullsend.yaml

prioritize.ymlAdd managed Prioritize workflow scaffold +46/-0

Add managed Prioritize workflow scaffold

• Introduces a new workflow_dispatch entrypoint that calls the pinned reusable-prioritize workflow. Defines required inputs, concurrency grouping per issue, permissions, and forwards standard fullsend vars/secrets including project_number and WIF/GCP credentials.

.github/workflows/prioritize.yml

@ggallen

ggallen commented Aug 22, 2026

Copy link
Copy Markdown
Member Author

Closing — will re-install after #6490 lands with project_number passthrough.

@ggallen ggallen closed this Aug 22, 2026
@ggallen
ggallen deleted the fullsend/scaffold-install branch August 22, 2026 19:40
@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (2)

Grey Divider


Action required

1. Missing Projects permission 🐞 Bug ⛨ Security
Description
.github/workflows/prioritize.yml does not grant projects: write, but the prioritize post-script
uses GitHub Projects V2 GraphQL APIs; with the default GITHUB_TOKEN this will 403 and can fail the
workflow when ORG/PROJECT_NUMBER are set. This prevents the prioritize agent from updating
project-board RICE fields as designed.
Code

.github/workflows/prioritize.yml[R7-12]

+permissions:
+  actions: write
+  contents: read
+  id-token: write
+  issues: write
+
Relevance

●●● Strong

Concrete functional bug: missing projects permission would break documented Projects V2 API usage.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The workflow explicitly scopes permissions and omits projects, while the prioritize GitHub ops
library documents that GH_TOKEN must have project write scope and then performs Projects V2
GraphQL calls (project view / field list / update). This combination causes authorization failure in
real runs that attempt board updates.

.github/workflows/prioritize.yml[7-12]
scripts/lib/github-prioritize-ops.lib.sh[12-16]
scripts/lib/github-prioritize-ops.lib.sh[52-55]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The prioritize workflow’s token lacks `projects: write`, but the prioritize post-script calls Projects V2 GraphQL operations (view project, list fields, update item field values). Without the permission, these calls will fail with 403 using the default `GITHUB_TOKEN`.

### Issue Context
The harness/scripts expect the GitHub token to have both issues write and project write capability for project-board updates.

### Fix Focus Areas
- .github/workflows/prioritize.yml[7-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Protected paths modified without issue 📜 Skill insight § Compliance
Description
This PR modifies protected governance/infrastructure paths under .github/ and .fullsend/ but the
PR description does not link an authorizing issue/ADR for these changes. Protected-path changes
require explicit authorization and must not be auto-approved.
Code

.github/workflows/prioritize.yml[R1-2]

+# This file is managed by fullsend. Do not edit it directly.
+# Upstream: https://github.com/fullsend-ai/fullsend/blob/main/internal/scaffold/fullsend-repo/.github/workflows/prioritize.yml
Relevance

●● Moderate

Compliance concern is plausible, but no closely matching authorization precedent found for
protected-path rule.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The compliance rule requires raising a finding whenever protected governance/infrastructure paths
are modified, with explicit justification via a linked issue/ADR. The diff adds a new workflow under
.github/workflows/ and changes .fullsend/config.yaml, both protected paths.

.github/workflows/prioritize.yml[1-46]
.fullsend/config.yaml[1-21]
Skill: pr-review

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR modifies protected governance/infrastructure paths (e.g., `.github/workflows/*`, `.fullsend/*`) without an explicit linked issue/ADR authorizing the change, which violates the protected-path review requirement.

## Issue Context
Protected-path changes require explicit authorization and manual review; the PR should reference the authorizing issue/ADR in the PR description (preferred) and/or in-file comments where applicable.

## Fix Focus Areas
- .github/workflows/prioritize.yml[1-4]
- .fullsend/config.yaml[1-21]
- .github/workflows/fullsend.yaml[45-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Unjustified workflow write permissions 📜 Skill insight ⛨ Security
Description
The new workflow grants broad write permissions (e.g., actions: write, id-token: write, `issues:
write`) without explicit least-privilege justification. Overbroad workflow token permissions
increase blast radius if the workflow is abused or misconfigured.
Code

.github/workflows/prioritize.yml[R7-11]

+permissions:
+  actions: write
+  contents: read
+  id-token: write
+  issues: write
Relevance

●● Moderate

Workflow permission security is scrutinized historically, but no exact precedent on unjustified
broad write scopes here.

PR-#80
PR-#776

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The compliance rule requires least-privilege review for permission-declaring files and mandates
explicit justification for permission expansions. The added workflow introduces a permissions:
block with multiple write scopes.

.github/workflows/prioritize.yml[7-12]
Skill: code-review

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new workflow declares elevated GitHub Actions token permissions without explicit least-privilege justification.

## Issue Context
Permission expansions in workflow manifests must follow least privilege and include an explicit authorization/justification (linked issue/ADR) for any expanded capability.

## Fix Focus Areas
- .github/workflows/prioritize.yml[7-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Config/docs schema mismatch 🐞 Bug ⚙ Maintainability
Description
.fullsend/config.yaml no longer declares an agents: list, but the repository documentation
instructs users to register per-repo harness overrides via .fullsend/config.yaml under agents:.
This inconsistency makes per-repo customization unclear and can break consumers that still expect
agents configuration.
Code

.fullsend/config.yaml[L15-16]

-agents:
-    - source: https://raw.githubusercontent.com/redhat-community-ai-tools/qualityflow-fullsend/f6311b4f30ee5c23c597dba07bccc8ac0aa991be/harness/qualityflow.yaml#sha256=c0a51b2f75172aebd577fd38c8012a7c566a84f84812ebd9aa4cc07ad3b2220e
Relevance

●●● Strong

Direct documentation/configuration contradiction is a clear, locally deterministic maintainability
issue.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The PR removes the agents: stanza from .fullsend/config.yaml, while the docs explicitly instruct
users to reference their custom harness in .fullsend/config.yaml using an agents: list. This is
a direct repo-internal contradiction introduced by the change.

.fullsend/config.yaml[6-20]
docs/code.md[142-150]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The scaffolded `.fullsend/config.yaml` removed the `agents:` section, but docs still describe configuring per-repo harness overrides by adding entries to `.fullsend/config.yaml.agents`. This creates conflicting guidance and increases the chance that per-repo installs are misconfigured.

### Issue Context
Either the docs need updating to the new roles-based config schema, or `.fullsend/config.yaml` should retain (or reintroduce) the documented `agents:` structure.

### Fix Focus Areas
- .fullsend/config.yaml[7-13]
- docs/code.md[142-150]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

5. Concurrency JSON parse fragile 🐞 Bug ☼ Reliability
Description
prioritize.yml builds its concurrency group with fromJSON(inputs.event_payload).issue.number,
which hard-fails if event_payload is not valid JSON or lacks .issue.number. A malformed dispatch
input will prevent the workflow from starting and/or cause unexpected concurrency collisions.
Code

.github/workflows/prioritize.yml[R26-28]

+concurrency:
+  group: fullsend-prioritize-${{ inputs.source_repo }}-${{ fromJSON(inputs.event_payload).issue.number }}
+  cancel-in-progress: true
Relevance

●● Moderate

Concurrency correctness accepted before, but no close precedent on fromJSON parsing fragility
specifically.

PR-#25

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The workflow’s concurrency group expression directly parses the event_payload input as JSON and
indexes into .issue.number, so invalid JSON or a missing field will break expression evaluation
for concurrency grouping.

.github/workflows/prioritize.yml[26-28]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The concurrency group uses `fromJSON()` on a free-form workflow_dispatch input, which can throw evaluation errors if the string isn’t valid JSON or doesn’t have the expected shape.

### Issue Context
This is especially brittle for manual runs or any caller that passes a different payload shape.

### Fix Focus Areas
- .github/workflows/prioritize.yml[26-28]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context sources
✅ Compliance rules (platform): 56 rules
✅ Skills: 4 invoked
  code-review
  code-implementation
  pr-review
  docs-review

Grey Divider

Tip of the day
💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment on lines +1 to +2
# This file is managed by fullsend. Do not edit it directly.
# Upstream: https://github.com/fullsend-ai/fullsend/blob/main/internal/scaffold/fullsend-repo/.github/workflows/prioritize.yml

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Protected paths modified without issue 📜 Skill insight § Compliance

This PR modifies protected governance/infrastructure paths under .github/ and .fullsend/ but the
PR description does not link an authorizing issue/ADR for these changes. Protected-path changes
require explicit authorization and must not be auto-approved.
Agent Prompt
## Issue description
The PR modifies protected governance/infrastructure paths (e.g., `.github/workflows/*`, `.fullsend/*`) without an explicit linked issue/ADR authorizing the change, which violates the protected-path review requirement.

## Issue Context
Protected-path changes require explicit authorization and manual review; the PR should reference the authorizing issue/ADR in the PR description (preferred) and/or in-file comments where applicable.

## Fix Focus Areas
- .github/workflows/prioritize.yml[1-4]
- .fullsend/config.yaml[1-21]
- .github/workflows/fullsend.yaml[45-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +7 to +11
permissions:
actions: write
contents: read
id-token: write
issues: write

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Unjustified workflow write permissions 📜 Skill insight ⛨ Security

The new workflow grants broad write permissions (e.g., actions: write, id-token: write, `issues:
write`) without explicit least-privilege justification. Overbroad workflow token permissions
increase blast radius if the workflow is abused or misconfigured.
Agent Prompt
## Issue description
The new workflow declares elevated GitHub Actions token permissions without explicit least-privilege justification.

## Issue Context
Permission expansions in workflow manifests must follow least privilege and include an explicit authorization/justification (linked issue/ADR) for any expanded capability.

## Fix Focus Areas
- .github/workflows/prioritize.yml[7-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +7 to +12
permissions:
actions: write
contents: read
id-token: write
issues: write

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. Missing projects permission 🐞 Bug ⛨ Security

.github/workflows/prioritize.yml does not grant projects: write, but the prioritize post-script
uses GitHub Projects V2 GraphQL APIs; with the default GITHUB_TOKEN this will 403 and can fail the
workflow when ORG/PROJECT_NUMBER are set. This prevents the prioritize agent from updating
project-board RICE fields as designed.
Agent Prompt
### Issue description
The prioritize workflow’s token lacks `projects: write`, but the prioritize post-script calls Projects V2 GraphQL operations (view project, list fields, update item field values). Without the permission, these calls will fail with 403 using the default `GITHUB_TOKEN`.

### Issue Context
The harness/scripts expect the GitHub token to have both issues write and project write capability for project-board updates.

### Fix Focus Areas
- .github/workflows/prioritize.yml[7-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread .fullsend/config.yaml
Comment on lines -15 to -16
agents:
- source: https://raw.githubusercontent.com/redhat-community-ai-tools/qualityflow-fullsend/f6311b4f30ee5c23c597dba07bccc8ac0aa991be/harness/qualityflow.yaml#sha256=c0a51b2f75172aebd577fd38c8012a7c566a84f84812ebd9aa4cc07ad3b2220e

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

4. Config/docs schema mismatch 🐞 Bug ⚙ Maintainability

.fullsend/config.yaml no longer declares an agents: list, but the repository documentation
instructs users to register per-repo harness overrides via .fullsend/config.yaml under agents:.
This inconsistency makes per-repo customization unclear and can break consumers that still expect
agents configuration.
Agent Prompt
### Issue description
The scaffolded `.fullsend/config.yaml` removed the `agents:` section, but docs still describe configuring per-repo harness overrides by adding entries to `.fullsend/config.yaml.agents`. This creates conflicting guidance and increases the chance that per-repo installs are misconfigured.

### Issue Context
Either the docs need updating to the new roles-based config schema, or `.fullsend/config.yaml` should retain (or reintroduce) the documented `agents:` structure.

### Fix Focus Areas
- .fullsend/config.yaml[7-13]
- docs/code.md[142-150]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +26 to +28
concurrency:
group: fullsend-prioritize-${{ inputs.source_repo }}-${{ fromJSON(inputs.event_payload).issue.number }}
cancel-in-progress: true

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Informational

5. Concurrency json parse fragile 🐞 Bug ☼ Reliability

prioritize.yml builds its concurrency group with fromJSON(inputs.event_payload).issue.number,
which hard-fails if event_payload is not valid JSON or lacks .issue.number. A malformed dispatch
input will prevent the workflow from starting and/or cause unexpected concurrency collisions.
Agent Prompt
### Issue description
The concurrency group uses `fromJSON()` on a free-form workflow_dispatch input, which can throw evaluation errors if the string isn’t valid JSON or doesn’t have the expected shape.

### Issue Context
This is especially brittle for manual runs or any caller that passes a different payload shape.

### Fix Focus Areas
- .github/workflows/prioritize.yml[26-28]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to 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.

1 participant