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.

On larger screens, the Repositories screen shows each provider's connected repositories as cards or as a compact list: switch between them in its toolbar. It opens the way you left it, with the same provider tab, view and visibility filter, even after the browser is closed. On a phone, the screen keeps its own presentation.

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.
• Concurrency groups exactly as GitHub runs them, for workflows and jobs alike (one namespace per repository): one run or job of a group at a time, cancel-in-progress, and queue — single keeps the newest one waiting, max up to 100 served in arrival order.
• 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.
• Pause switches at two levels — disable one noisy workflow, or flip the repository's master switch to pause all of its CI. A paused pipeline stops triggering (pushes, schedules, manual dispatch) but stays listed with its history; both switches default to on.

Portable workflows#

A workflow written for GitHub runs here unchanged. A few things are worth knowing:

• secrets.GITHUB_TOKEN is provided for you, as on GitHub: it is the connected repository's installation token, and ${{ github.token }} is the same value. You never declare it — none of your own secrets may be named GITHUB_*.
• EQUANTIC_SPACE is true in every step. Everything else in the environment impersonates the provider on purpose (GITHUB_ACTIONS=true, GITHUB_SERVER_URL=https://github.com) so that real actions behave exactly as they do on GitHub — which leaves this as the one variable a workflow can read to know where it is running, for the rare step that has to differ.
• actions/cache works against our own cache service, in both protocol versions the action knows. cache-from: type=gha in a Docker build uses the same store.
• Your checkout is where GitHub puts it: $GITHUB_WORKSPACE is /home/runner/work/<repo>/<repo>, and its parent is $RUNNER_WORKSPACE, which your job owns. So a step writes beside the checkout the way workflows do it — git clone … ../<repo>.wiki to read a repository's wiki, a build output kept out of the tree — and ${{ runner.workspace }} is that parent, as on a hosted runner.
• All three kinds of action run: JavaScript, composite and Docker. A Docker action runs as a container beside your job, with your workspace mounted where GitHub mounts it (/github/workspace) — a docker:// image is pulled, an action shipping a Dockerfile is built on the spot. The only parts not run are runs.pre-entrypoint and runs.post-entrypoint, and the step says so in the log instead of skipping them quietly.
• shell: is the shell you asked for: bash, sh, python, pwsh, or a custom template such as bash -e {0}. An interpreter the image does not have fails the step by name, rather than running your script as something else. defaults.run applies at the workflow and job level, for both shell and working-directory.
• github.event is the delivered payload, so github.event.pull_request.number, github.event.head_commit.message and contains(github.event.pull_request.labels.*.name, …) read as they do on GitHub. github.event_name says what actually happened, and a manually dispatched run's inputs arrive in both inputs and github.event.inputs.

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.