I’ve ran into this problem in two different projects and can’t get around it, and AI FDE just keeps trying to work around it and solve it and finally gave up. I am posting the AI FDE summary of the bug:
_________________________________________________
A code repository generated from pilot-template version 0.64.0 has ci/osdk-app-publish configured as a required check, but the template does not ship a ci.yml for that job to be defined in. As a result the checks runner fails after two to four seconds on every commit and every branch, and has done so since the repository was created — the failure appears on the initial commit on master, not just on feature branches. The error is simply Could not find configuration file for checks, checked the following location: 'ci.yml', meaning a required check points at a job that was never defined and can therefore never pass.
Writing a ci.yml by hand gets past the parse error and the check does begin to execute, cloning the repository and restoring caches before failing on node: command not found, alongside a warning that the job lacks read permissions for four backing repositories including the Node.js bundle. Both of those turn out not to be user misconfiguration: all four artifact repositories are already imported into the containing project, and the Node.js bundle is already listed as a backing repository on the code repository itself, yet the CI job’s identity still cannot read them. The template also ships a gradle.properties pinning a Node installation version while providing no build.gradle, gradlew or settings.gradle for anything to act on, which suggests the Gradle-driven Node provisioning the template assumes was simply never generated.
The practical impact is that pull requests cannot merge and tag-based publishing does not work. With no ci.yml the pull request offers a “merge at your own risk” escape hatch, but once a ci.yml exists the check actively fails and the merge button is disabled outright with “Unable to evaluate whether a job specs cycle would be introduced because checks failed” — so a failing check blocks harder than an absent one, and neither state allows a normal merge. Creating a release tag produces a build that fails for the same reason, making the documented publish path unavailable. Compounding this, the template’s own .husky/pre-commit hook cannot find npm on the PATH in the git hook environment, so every commit must be made with --no-verify, which means an affected repository has no functioning quality gate either locally or in CI. The changes in question were ultimately merged by pushing directly to an unprotected master, and the application was deployed by building dist/ and uploading it manually through Developer Console, both of which bypass the broken machinery rather than fix it.
