Repositories & CI/CD
Connect repositories and run pipelines on the eQuantic Runners.
Connect repositories
Use the GitHub App (recommended) for fine-grained, organization-managed permissions, with short-lived installation tokens. Azure DevOps is now supported: connect an organization with a Personal Access Token and pick its repositories (org/project/repo) — webhooks (Service Hooks) are configured automatically. GitLab is available too: connect with a Personal Access Token — gitlab.com or your own self-hosted instance — and pick its projects (deeply nested subgroups included); webhooks are set up automatically. Bitbucket is a first-class provider as well: connect a Bitbucket workspace with an app password or an Atlassian API token (with your account e-mail) and pick its repositories (workspace/repo); webhooks are configured automatically. GitHub, GitLab, Bitbucket and Azure DevOps are all fully supported.
Pipelines
The platform interprets your GitHub Actions, Azure Pipelines (azure-pipelines.yml), GitLab CI (.gitlab-ci.yml) and Bitbucket Pipelines (bitbucket-pipelines.yml) YAML and runs the jobs on the eQuantic Runners. Features:
- Job graph derived from
needs:dependencies, with matrix builds expanding into parallel nodes. - Real Azure Pipelines tasks for
task:steps, resolved from your own organization (marketplace tasks included); PowerShell-only tasks and service connections aren't supported yet. - Live logs per step, with re-run of everything / failures only / an individual job.
- Visual step editor (drag and drop) and an advanced editing mode for the YAML.
- Manual approval before production deploy (N-of-M quorum) and protected environments.
- Configurable cache and per-repository secrets/variables, with references to service variables.
Pull requests
When a repository is connected (GitHub, GitLab, Bitbucket or Azure DevOps), you can choose to manage its Pull Requests inside eQuantic instead of on the provider — an opt-in per repository. The code always stays on the provider; eQuantic never hosts the git.
- Opt-in on the Pull requests tab — activate eQuantic-managed PRs, or keep using the provider's PRs (the default).
- PR creation — pick source → target branch, plus title and description; each PR gets a per-repository number.
- List with states — open / draft / merged / closed, filterable.
- Diff view — eQuantic computes the diff itself (three-dot, against the merge-base, like the provider UIs) and stores it: the detail screen shows a summary (files changed, +additions −deletions) and per-file unified hunks with exact line numbers. Binary files and very large diffs are flagged instead of rendered; new pushes to the source branch refresh the diff automatically via the repository webhook.
- Code review on the diff — comment on any diff line: threads anchor to the exact line, with replies and resolve/unresolve. When new commits arrive, existing threads are never lost — they're flagged as outdated and grouped per file.
- Blocking comments — a review comment can be marked as blocking; unresolved blocking comments are surfaced prominently on the PR (banner plus list indicator), and only their author can resolve them.
- Approvals & conversation — reviewers approve or request changes (one current verdict per reviewer; the PR author can't review their own PR), with approved/changes-requested counts on the PR and in the list — plus a general comment feed on the PR, alongside the line threads.
- Branch protection — in the repository settings, define rules per branch pattern (
main,release/*): minimum number of approvals, linear history, requiring the branch to be up to date with the target, dismissing stale approvals when new commits arrive, and whether unresolved blocking comments veto the merge — plus the allowed merge strategies and the default one. - Merge inside eQuantic — when every condition passes (approvals, no changes requested, no unresolved blocking comments, protection rules), the PR can be merged as a merge commit, squash or rebase. eQuantic performs the merge itself and pushes the result to the provider — never through the provider's merge API, and never with a force-push. While blocked, the PR lists exactly what's missing; a PR can also be closed without merging.
- Merge queue — instead of merging directly, a PR can enter its target branch's merge queue. Entries land in order: each one is tested against the current state of the target — so a branch that fell behind needs no manual updating, and joining the queue is allowed even while it's out of date — and, if every condition still holds at land time, eQuantic performs the merge and pushes it. A conflict or an unmet condition drops the entry with the reason and the next one proceeds; entries still waiting can leave the queue, and the queue panel on the Pull requests tab shows positions and live status.
- CI checks — pipeline runs on the PR's commits report their status natively on the PR: one check per workflow, per commit — pending, success or failure — shown in the merge panel. A branch protection rule can also require checks: the PR only merges once every reported check has passed — a failed or still-running check blocks the merge, and so does having no reported check at all (a required check never passes silently). The same requirement gates entries landing through the merge queue.
Preview environments
Every open Pull Request can get an ephemeral preview environment — an isolated service built from the PR branch and deployed with its own URL (pr-N.preview.<deploy-domain>).
- Per-repository config on the Previews tab: the auto-preview toggle, the target Space and an optional base environment whose variables are cloned into each preview.
- Automatic lifecycle — PR opened → environment provisioned; new pushes → redeploy; merge/close → teardown. The card shows the live status (building → ready / failed), the URL, branch/commit and author.
- Manual mode — the tab lists open PRs without a preview, one click away from creating one; existing previews can be rebuilt or destroyed from the card menu.
- The preview URL is posted as a comment on the PR and kept up to date.