Projects and builds

A project connects GitMyABI to a single GitHub repository that contains your smart contract source. Each project carries its build configuration: framework, build commands, environment variables, and publishing options.

A build is one execution of that configuration against a specific build reference — a branch, tag, release, or commit. A successful build extracts the contract artifacts and publishes them through the configured channels.

What a project contains

• A connected GitHub repository. GitMyABI sources contract code from GitHub only.
• A framework. Hardhat or Foundry. The framework determines the default build commands and the default artifacts path.
• A branch. The branch chosen at project creation drives the default build reference and the list of branches offered for new builds.
• A root directory. The path inside the repository that contains the smart contract project, when the contracts are not at the repository root.
• Build settings. Artifacts path, install command, build command, and test command, plus any environment variables.
• An npm publishing setting. A single visibility flag that controls whether the published bindings package is publicly installable.

What a build does

A build runs the project's configured install, build, and (optionally) test commands against the chosen Git reference, then extracts the compiled ABIs from the artifacts path and publishes them. The full pipeline — from clone to artifact publish — is documented in ABI and TypeScript bindings publishing.

Build references

Every build is tied to a single Git reference. References fall into two groups:

• Moving references. A branch points at the latest build for that branch. The same branch alias resolves to different builds over time.
• Fixed references. A tag, a release, or a commit hash points at one specific build. Once published, the artifact at that reference does not change.

Build lifecycle

A build progresses through a small set of statuses, each surfaced in the build list and on the build detail page:

• Pending — queued, waiting for an executor.
• Running — install, build, and publish steps are executing.
• Success — artifacts are available on the CDN and the npm package has been published.
• Failed — a step exited non-zero; the build log on the detail page records which step failed.
• Cancelled — the build was stopped before completion.

What a successful build produces

• One or more ABI JSON files, served from a public CDN URL shown on the build detail page.
• A TypeScript bindings package published to an npm registry, with the package name, version, install command, and registry configuration shown on the build detail page.
• Build logs, plus downloadable artifacts where the project plan supports them.

The shape of each artifact is documented in review the package format.

What is preserved across builds

• Project configuration persists. Editing it changes the configuration used for the next build, not for past builds.
• Each build has its own version. The version shown on the build detail page identifies the npm package version for that build.
• Build retention and auto-build behaviour depend on the project plan; see billing and subscriptions.