Repository navigation
Implement strict package.json-based repository configuration for fork compatibility - #968
Conversation
|
I don't want to use the access URL approach as that is not reliable. Configuration approach is more reliable. It could also be a variable that gets set on a build that is used by the deployment scripts to then set a configuration parameter @copilot |
Co-authored-by: litlfred <662242+litlfred@users.noreply.github.com>
Implemented the configuration-based approach as requested. The solution extracts repository information from git remote/package.json at build time and sets environment variables, avoiding URL-based detection. Key components:
Both Commit: f8e5a6b |
Co-authored-by: litlfred <662242+litlfred@users.noreply.github.com>
🚀 Deployment Status: Ready for Deployment ✅🔗 Quick Actions: 📝 Recent Change SummaryLatest commit: 📊 Overall ProgressBranch: 💡 Click deploy link above, then "Run workflow". Branch name will be pre-filled. |
- Generated service table from current codebase - Updated FAQ question ID enum with questions - Links to schemas and OpenAPI specs updated Generated by: scripts/generate-service-table.js Timestamp: 2025-09-13T07:30:12+00:00
🔍 Page Framework Compliance Check ResultsFramework Structure Compliance
🔍 SGEX Page Framework Compliance CheckerFalling back to directory scan... ✅ ActorEditor: 6/6 (100%) - COMPLIANT ✅ BPMNEditor: 6/6 (100%) - COMPLIANT
✅ BPMNSource: 6/6 (100%) - COMPLIANT ✅ BPMNViewer: 6/6 (100%) - COMPLIANT
✅ BusinessProcessSelection: 6/6 (100%) - COMPLIANT
✅ ComponentEditor: 6/6 (100%) - COMPLIANT ✅ CoreDataDictionaryViewer: 6/6 (100%) - COMPLIANT ✅ DAKActionSelection: 6/6 (100%) - COMPLIANT
✅ DAKConfiguration: 6/6 (100%) - COMPLIANT ✅ DAKDashboard: 6/6 (100%) - COMPLIANT ✅ DAKDashboardWithFramework: 6/6 (100%) - COMPLIANT
✅ DAKSelection: 6/6 (100%) - COMPLIANT
✅ DashboardRedirect: 6/6 (100%) - COMPLIANT ✅ DecisionSupportLogicView: 6/6 (100%) - COMPLIANT
✅ FeatureFileEditor: 6/6 (100%) - COMPLIANT
✅ NotFound: 6/6 (100%) - COMPLIANT ✅ OrganizationSelection: 6/6 (100%) - COMPLIANT
✅ RepositorySelection: 6/6 (100%) - COMPLIANT
✅ SelectProfilePage: 6/6 (100%) - COMPLIANT
✅ WelcomePage: 6/6 (100%) - COMPLIANT
📊 COMPLIANCE SUMMARY✅ Fully Compliant: 20/51 📈 Overall Compliance: 39%
✅ COMPLIANCE CHECK PASSED Profile Creation ComplianceStatus: ✅ PASSED
🔍 Starting Profile Creation Compliance Check... 📊 Profile Creation Compliance Report📁 Files scanned: 140 ✅ COMPLIANCE PASSED: No profile creation violations found! Next StepsFor guidance, see: |
🔒 Dependency Security Check Results |
|
@copilot where are there references to @litlfred/sgex left ? |
❌ Branch Preview Failed!Branch: 🔍 Troubleshooting Actions
💡 Common Issues
📋 InstructionsTo retry: Click "RETRY BUILD" above, then click "Run workflow" (branch name will be pre-filled) ❗ Please check the build logs above and fix any issues before restarting the deployment. Note: The previous deployment (if any) remains active until this branch is successfully deployed. |
|
@copilot litlfred/sgex is used as a fallback repository in a couple of locations that are hard-coded. There should be a central variable called faultback repo that's used instead of the multiple instances. In the repository-config.js there is attempt to get it from package.json as well as the git remote. It's these two different then it should not build an issue of warning about needing to update package.json to match the remote or to change their remote/upstream origin. |
…ository configuration Co-authored-by: litlfred <662242+litlfred@users.noreply.github.com>
I've systematically identified and replaced all remaining Core Services:
UI Components (11 files):
Key Exclusions:
The only remaining
All functional code now uses dynamic repository configuration, making forks automatically work without any code changes. Commit: 0f8e81f |
Co-authored-by: litlfred <662242+litlfred@users.noreply.github.com>
Implemented both requested improvements: 1. Central Fallback Repository Variable:
2. Repository Mismatch Detection:
The system now provides better fork compatibility with centralized configuration and helpful warnings when repository settings are inconsistent. Commit: e54eb83 |
- Generated service table from current codebase - Updated FAQ question ID enum with questions - Links to schemas and OpenAPI specs updated Generated by: scripts/generate-service-table.js Timestamp: 2025-09-13T07:58:40+00:00
|
@copilot build error 48s
Skipping prebuild due to TypeScript errors
🔧 Configuring repository settings for build... [eslint] src/components/WorkflowDashboard.js npm notice |
|
Actually instead of hard-coded fallback constant it should use what is in package.json. if it is not present there, then it should fail If upstream git is different than package.json it should fail Please review all code that was changed in this PR or to see if there is opportunity to consolidate redundant code |
…tName() calls Co-authored-by: litlfred <662242+litlfred@users.noreply.github.com>
Fixed the syntax errors that were preventing the build from compiling. The issues were missing closing parentheses in BranchListingPage.js: Fixed 7 instances where All files now pass syntax validation with Commit: ffe638b |
…sted Co-authored-by: litlfred <662242+litlfred@users.noreply.github.com>
Implemented the strict package.json-based configuration as requested. Key changes: Removed hardcoded fallback constant: Eliminated Enforced package.json requirement: Build now fails with clear error if repository field is missing from package.json. Enforced git remote consistency: Build fails if git remote origin differs from package.json repository, with specific commands to fix the mismatch. Consolidated redundant code: Updated scripts to use shared The system now uses package.json as the single source of truth, fails fast on configuration errors, and provides clear guidance for fixing issues. Commit: f1f38e9 |
- Generated service table from current codebase - Updated FAQ question ID enum with questions - Links to schemas and OpenAPI specs updated Generated by: scripts/generate-service-table.js Timestamp: 2025-09-13T09:25:04+00:00
✅ Branch Preview Ready!Branch: 🌐 Preview URLs
🔄 Deployment Actions
📋 InstructionsTo redeploy: Click "REDEPLOY BRANCH" above, then click "Run workflow" (branch name will be pre-filled) 💡 This branch preview was deployed successfully and will remain until the next deployment. Note: This deployment only updates the branch subdirectory and does not affect the landing page. |
Create centralized fallback repository constant to eliminate hardcoded referencesRemove all hardcoded fallback constantswarningsstrict validation failuresIssues Addressed
Fixes #967
Implementation Summary
Strict Package.json-Based Configuration: Following feedback, this implementation now enforces a strict requirement for valid repository configuration in package.json and validates consistency with git remotes, eliminating all hardcoded fallbacks and failing fast on configuration errors.
Key Components
Strict Configuration System
src/config/repositoryConfig.js- Repository configuration service that requires build-time environment variables (no fallbacks allowed)scripts/configure-repository.js- Build script that enforces package.json repository field requirement and validates git remote consistencynpm startandnpm run buildautomatically configure and validate repository settings with strict error handlingRepository Validation Requirements
Strict Validation Features
FALLBACK_REPOSITORYor hardcoded repository references anywhereUpdated Services (Consolidated)
generate-service-table.jsandgenerate-qa-report.jsupdated to use new strict validation functionsUpdated Components
Fork Compatibility Features
Strict Validation: Forks must have correct package.json repository field and matching git remote - no exceptions
Build-Time Enforcement: Configuration errors are caught early in build process with clear, actionable guidance
No Fallbacks: Eliminates configuration confusion by requiring explicit, validated repository setup
Complete Coverage: All repository references now dynamically configured from single validated source
Testing Completed
Latest Changes
Strict Configuration Enforcement
FALLBACK_REPOSITORYanywhere in the codebaseextractRepositoryInfo→getRepositoryFromPackageJsonfor clarityCode Consolidation
This solution provides strict, reliable repository configuration that requires explicit package.json setup and validates consistency, making it truly fork-friendly while preventing configuration errors through build-time validation.
Addressing #967.
Participants: @litlfred
This PR addresses the strict package.json-based configuration improvements requested. Please review when ready.
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.