Skip to content

chore: resolve merge with master — keep OIDC PyPI workflows#87

Merged
bbartling merged 25 commits intomasterfrom
develop/v2.0.8
Mar 26, 2026
Merged

chore: resolve merge with master — keep OIDC PyPI workflows#87
bbartling merged 25 commits intomasterfrom
develop/v2.0.8

Conversation

@bbartling
Copy link
Copy Markdown
Owner

@bbartling bbartling commented Mar 25, 2026

Summary by CodeRabbit

  • Chores

    • Updated Python runtime version from 3.12 to 3.14 in CI workflows
    • Migrated PyPI package publishing to use OIDC-based authentication instead of token-based credentials
  • Documentation

    • Updated PyPI publishing setup guide with new authentication configuration requirements and troubleshooting guidance

This keeps Python and frontend package metadata aligned for the new development cycle on develop/v2.0.7.

Made-with: Cursor
- Add test_bench_rule_catalog and rules_reference YAML; SPARQL smoke table in cookbook
- MCP RAG: empty upstream body handling, SearchApiCapabilitiesRequest with extra ignore
- Bootstrap tests: timeout, stderr for invalid --mode
- E2e/fake BACnet: dedupe Plots helpers, task refs + stop(), monitor RPC guards, CRLF .cmd + .gitattributes
- Misc: fix_dpkg paths, 4_hot_reload JSON error detail, docs nits

Made-with: Cursor
…esting_layers + session trail

Made-with: Cursor
Add references/legacy_automated_testing.md with full path map from
bbartling/open-fdd-automated-testing into open-fdd, deprecation README
snippet, and roadmap for lab vs AI modeling vs live operator.

SKILL.md: explain AgentSkills shape, bundled vs repo skill, and link legacy
doc; expand AI modeling and live HVAC sections.

Point root README, HANDOFF_PROTOCOL, openclaw_context_bootstrap, long run
paste block, skill_installation, and issues_log at the canonical openclaw tree.

Made-with: Cursor
Add references/session_status_summary.md with mandatory output shape,
human paste prompt, and agent checklists (issues_log sections, PIDs, log
paths, edge cases). Wire SKILL, HANDOFF_PROTOCOL, long_run_lab_pass,
api_throttle, issues_log rules, README, and openclaw_context_bootstrap.

Made-with: Cursor
Add howto/engine_only_iot.md comparing bootstrap --mode engine (Docker)
vs library RuleRunner for external collection/modeling. Link from modular
architecture, howto index, and openfdd-engine README.

Made-with: Cursor
- Add publish-open-fdd.yml (tag open-fdd-v*, secret PYPI_OPENFDD_TOKEN)
- Rewrite openfdd_engine_pypi.md: both packages, order, local dry run
- Align README, technical_reference, _config, standalone_csv_pandas with
  2.x PyPI = engine + extras; edge stack from repo

Made-with: Cursor
- Bump open-fdd to 2.0.8 in root pyproject.toml
- Bump frontend package.json + package-lock.json to 2.0.8
- Bump openfdd-engine to 0.1.1, require open-fdd>=2.0.8
- Handoff/long_run: generic branch placeholders; issues_log release note

Made-with: Cursor
- Use Python 3.14 in publish-open-fdd and publish-openfdd-engine workflows
- Explain 403 is token/project permissions, not runner Python version
- Note per-project API tokens for both secrets

Made-with: Cursor
Replace twine + empty TWINE_PASSWORD with pypa/gh-action-pypi-publish and
id-token: write. Configure each PyPI project with a GitHub publisher for the
matching workflow file. Document setup and token fallback in openfdd_engine_pypi.md.

Made-with: Cursor
@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 25, 2026

📝 Walkthrough

Walkthrough

CI/CD workflows are updated to use PyPI Trusted Publishing with OIDC instead of token-based authentication, Python runtime upgraded from 3.12 to 3.14, and documentation updated to reflect the new authentication mechanism and troubleshooting guidance.

Changes

Cohort / File(s) Summary
PyPI Publishing Workflows
.github/workflows/publish-open-fdd.yml, .github/workflows/publish-openfdd-engine.yml
Workflows now request id-token: write permissions, upgrade Python from 3.12 to 3.14, and replace manual twine upload commands with pypa/gh-action-pypi-publish@release/v1 action for OIDC-based authentication to PyPI.
PyPI Publishing Documentation
docs/howto/openfdd_engine_pypi.md
Documentation updated to guide users away from storing PyPI tokens in GitHub Secrets toward PyPI Trusted Publishing (OIDC) setup. Adds explicit configuration steps for registering GitHub publishers on PyPI projects and updates CI troubleshooting to address OIDC-related issues, with optional token-based fallback instructions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 From tokens old to OIDC's glow,
Three-twelve to three-fourteen we grow,
GitHub publishes with trust so true,
PyPI greets our secrets new,
No more passwords stored away! 🚀

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'chore: resolve merge with master — keep OIDC PyPI workflows' accurately describes the main objective: resolving a merge conflict while preserving the OIDC-based PyPI authentication changes across workflow files.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch develop/v2.0.8

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/publish-open-fdd.yml:
- Around line 36-38: Replace the mutable ref
pypa/gh-action-pypi-publish@release/v1 with an immutable full commit SHA to
harden the workflow: locate the uses entry referencing
"pypa/gh-action-pypi-publish@release/v1" and change it to
"pypa/gh-action-pypi-publish@<full-commit-sha>" (use the repository commit SHA
you validated), keep the existing with: packages-dir: dist/ intact, and commit
the updated workflow so the action is pinned to that specific immutable commit.

In @.github/workflows/publish-openfdd-engine.yml:
- Around line 35-37: Replace the mutable tag in the GitHub Actions step that
uses "pypa/gh-action-pypi-publish@release/v1" by pinning to a full commit SHA
(e.g., @<full-commit-sha>) and add an inline comment indicating the readable
version (for example: # release/v1) to retain clarity; update the "uses:
pypa/gh-action-pypi-publish@release/v1" line to reference the full SHA so the
action is immutable and follows the security best practice described in the
review.

In `@docs/howto/openfdd_engine_pypi.md`:
- Around line 50-55: The snippet uses packages-dir: dist/ which is correct for
open-fdd but wrong for the openfdd-engine workflow; update the docs to clarify
the fallback path for the openfdd-engine workflow by adding or replacing the
example to show packages-dir: packages/openfdd-engine/dist/ (or state both
options and instruct readers to use the engine-specific path when publishing
openfdd-engine), and mention the exact YAML key packages-dir so readers know
which value to change.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 343978c4-b43d-4593-92c6-ee21fb0c8af0

📥 Commits

Reviewing files that changed from the base of the PR and between 1e2d420 and c0df15a.

📒 Files selected for processing (3)
  • .github/workflows/publish-open-fdd.yml
  • .github/workflows/publish-openfdd-engine.yml
  • docs/howto/openfdd_engine_pypi.md

Comment on lines +36 to +38
uses: pypa/gh-action-pypi-publish@release/v1
with:
packages-dir: dist/
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Current workflow references:"
rg -n 'gh-action-pypi-publish@' .github/workflows

echo
echo "Resolve current commit behind release/v1:"
gh api repos/pypa/gh-action-pypi-publish/commits/release/v1 --jq '.sha'

Repository: bbartling/open-fdd

Length of output: 490


🏁 Script executed:

# Verify the exact content of the file at the specified lines
cat -n .github/workflows/publish-open-fdd.yml | sed -n '30,45p'

Repository: bbartling/open-fdd

Length of output: 519


🌐 Web query:

GitHub Actions pinning to commit SHA security best practices

💡 Result:

Pinning GitHub Actions to a full-length commit SHA is the recommended security best practice to ensure immutability and prevent supply chain attacks where malicious code could be injected via tag overwrites. Key best practices: - Always pin to full-length commit SHAs (40 characters), not short SHAs or tags like 'v1'. Example: - uses: actions/checkout@692973e # v4.1.7 Verify the SHA is from the official repository, not a fork. - Prioritize high-risk third-party actions (those handling secrets or sensitive operations). - Use GitHub policies to enforce SHA pinning at repository/organization level. - Periodically update pins using Dependabot or Renovate (they recognize version comments like # v4.1.7). - Audit action source code and prefer verified creators from GitHub Marketplace. - Tools like Hyland/github-actions-ensure-sha-pinned-actions can automate conversion of tags to SHAs. - Combine with other hardening: minimize GITHUB_TOKEN permissions, use OIDC, restrict permissions. This mitigates risks like tag force-pushing malicious code, as SHAs are immutable (requiring SHA-1 collision attacks, which are infeasible). Note: SHA-pinned actions won't get Dependabot vulnerability alerts (only for semver tags), so monitor manually or via other tools.

Citations:


🏁 Script executed:

# Check how other actions are pinned in this workflow file
cat -n .github/workflows/publish-open-fdd.yml | head -40

Repository: bbartling/open-fdd

Length of output: 1270


🏁 Script executed:

# Check both workflow files that reference gh-action-pypi-publish
echo "=== publish-open-fdd.yml ===" && grep -A 2 -B 2 'gh-action-pypi-publish' .github/workflows/publish-open-fdd.yml
echo
echo "=== publish-openfdd-engine.yml ===" && grep -A 2 -B 2 'gh-action-pypi-publish' .github/workflows/publish-openfdd-engine.yml

Repository: bbartling/open-fdd

Length of output: 528


Pin gh-action-pypi-publish to an immutable commit SHA.

Line 36 uses @release/v1, a mutable ref that can be exploited for supply chain attacks if the tag is force-pushed. Pinning to a full-length commit SHA hardens the release pipeline against upstream tag overwrites.

🔒 Suggested change
-        uses: pypa/gh-action-pypi-publish@release/v1
+        uses: pypa/gh-action-pypi-publish@<FULL_LENGTH_COMMIT_SHA>
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish-open-fdd.yml around lines 36 - 38, Replace the
mutable ref pypa/gh-action-pypi-publish@release/v1 with an immutable full commit
SHA to harden the workflow: locate the uses entry referencing
"pypa/gh-action-pypi-publish@release/v1" and change it to
"pypa/gh-action-pypi-publish@<full-commit-sha>" (use the repository commit SHA
you validated), keep the existing with: packages-dir: dist/ intact, and commit
the updated workflow so the action is pinned to that specific immutable commit.

Comment on lines +35 to +37
uses: pypa/gh-action-pypi-publish@release/v1
with:
packages-dir: packages/openfdd-engine/dist/
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# Check if the file exists and read its contents
cat -n .github/workflows/publish-openfdd-engine.yml

Repository: bbartling/open-fdd

Length of output: 1177


🌐 Web query:

GitHub Actions @release/v1vs@v4 mutable pinning commit SHA best practices

💡 Result:

GitHub Actions best practices recommend pinning actions to full commit SHAs for maximum security against supply chain attacks, as tags like @v4 or @release/v1 are mutable and can be retargeted to malicious commits. @v4 refers to the latest minor/patch in the v4 major version (e.g., actions/checkout@v4 points to the current v4.x.x tag), while @release/v1 likely refers to a custom or action-specific tag like 'release/v1' in some release management actions (e.g., similar to ncipollo/release-action's v1 tag management), which is also mutable. SHA pinning example: uses: actions/checkout@08c6903 # v5.0.0 Add the version comment for readability and Dependabot/Renovate updates. Official GitHub docs emphasize SHA pinning for third-party actions, with policies to enforce it organization-wide. Major version tags (@v4) balance usability and security if you trust the creator, but SHA is preferred. Use tools like pinata, Renovate's pinGitHubActionDigestsToSemver, or Dependabot for automation. @release/v1 vs @v4: Both mutable tags; no specific distinction found, but treat as equivalent risk level—pin to SHA regardless.

Citations:


🏁 Script executed:

# Check for other workflow files
find .github/workflows -name "*.yml" -o -name "*.yaml" | head -20

Repository: bbartling/open-fdd

Length of output: 170


🏁 Script executed:

# Check the other workflow files for action pinning patterns
echo "=== ci.yml ===" && head -40 .github/workflows/ci.yml && echo -e "\n=== publish-open-fdd.yml ===" && head -40 .github/workflows/publish-open-fdd.yml

Repository: bbartling/open-fdd

Length of output: 1992


Pin the publish action to a full commit SHA.

On line 35, @release/v1 is a mutable tag and poses a supply chain security risk. Pin pypa/gh-action-pypi-publish to a full commit SHA with a version comment for readability, following GitHub Actions security best practices.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish-openfdd-engine.yml around lines 35 - 37, Replace
the mutable tag in the GitHub Actions step that uses
"pypa/gh-action-pypi-publish@release/v1" by pinning to a full commit SHA (e.g.,
@<full-commit-sha>) and add an inline comment indicating the readable version
(for example: # release/v1) to retain clarity; update the "uses:
pypa/gh-action-pypi-publish@release/v1" line to reference the full SHA so the
action is immutable and follows the security best practice described in the
review.

Comment on lines +50 to +55
```yaml
uses: pypa/gh-action-pypi-publish@release/v1
with:
packages-dir: dist/
password: ${{ secrets.PYPI_OPENFDD_TOKEN }}
```
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Clarify fallback snippet for openfdd-engine path.

The example on Lines 50-55 uses packages-dir: dist/, which is correct for open-fdd but not for openfdd-engine (that workflow uses packages/openfdd-engine/dist/). A copy/paste here can cause failed uploads.

📝 Suggested doc tweak
 uses: pypa/gh-action-pypi-publish@release/v1
 with:
   packages-dir: dist/
   password: ${{ secrets.PYPI_OPENFDD_TOKEN }}
+
+# For openfdd-engine workflow, use:
+# packages-dir: packages/openfdd-engine/dist/
+# password: ${{ secrets.PYPI_OPENFDD_ENGINE_TOKEN }}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/howto/openfdd_engine_pypi.md` around lines 50 - 55, The snippet uses
packages-dir: dist/ which is correct for open-fdd but wrong for the
openfdd-engine workflow; update the docs to clarify the fallback path for the
openfdd-engine workflow by adding or replacing the example to show packages-dir:
packages/openfdd-engine/dist/ (or state both options and instruct readers to use
the engine-specific path when publishing openfdd-engine), and mention the exact
YAML key packages-dir so readers know which value to change.

Made-with: Cursor

# Conflicts:
#	docs/howto/openfdd_engine_pypi.md
@bbartling bbartling merged commit a7f3df4 into master Mar 26, 2026
2 checks passed
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