Connect and set up
Supported technology
What Yavaren does with each work tracker, repository host and code agent, and where one works differently.
Every work tracker, repository host and code agent below is supported for the whole path: reading a story, drafting the change, opening a draft pull request, and learning from what happens to it. Where a service's own interface cannot do something, Yavaren does the closest thing it can, and the list under each table says what and why.
Work trackers
| Azure DevOps Boards | Jira | GitHub Issues | GitLab Issues | Yavaren Boards (built in) | |
|---|---|---|---|---|---|
| Read a story with its acceptance criteria | Yes | Yes | Yes | Yes | Yes |
| Attachments and documents (PDF, Word, images) | Yes | Yes | Yes | Yes | Yes |
| Read comments | Yes | Yes | Yes | Yes | Yes |
| Write comments (the brief, notes) | Yes | Yes | Yes | Yes | Yes |
| Move an item to a workflow state | Yes | Yes | Yes, differently | Yes, differently | Yes |
| Assign items to the requirement's creator | Yes | Yes | Yes | Yes | Yes |
| Requirement pipeline write-back (brief, features, stories) | Yes | Yes | Yes | Yes | Yes |
| Approvals and gates found in the tracker | Yes | Yes | Yes | Yes | Yes |
| Link the story to its draft pull request | Yes | Yes | Yes | Yes | Yes |
| Webhooks (start work when an item is labelled) | Yes | Yes | Yes | Yes | Yes |
| Pagination of every list | Yes | Yes | Yes | Yes | Yes |
| Delivery history: every epic, feature and story of the last years (the project's domain) | Yes | Yes | Yes | Yes | Yes |
| Rate limits and retries | Yes | Yes | Yes | Yes | Yes |
| Self-hosted / on-premises edition | Yes | Yes | Yes | Yes | Yes |
| Authentication | Yes | Yes | Yes | Yes | Yes |
Where a service works differently, and why:
- GitHub Issues, move an item to a workflow state: open / closed; any other state name is applied as a label. An issue has two states in the REST API; a board's Status lives in GitHub Projects (GraphQL, a field of one project), not on the issue
- GitLab Issues, move an item to a workflow state: opened / closed (state_event); any other state name is applied as a label. The REST API has two issue states; a scoped label such as workflow::Review is exclusive on GitLab Premium, and the newer issue Status is GraphQL only
Repository hosts
| Azure Repos | GitHub | GitLab | Bitbucket Cloud | Bitbucket Server / Data Center | |
|---|---|---|---|---|---|
| Open a draft pull request | Yes | Yes | Yes | Yes | Yes, differently |
| Update the description of an existing pull request | Yes | Yes | Yes | Yes | Yes |
| Take a pull request out of draft (when a project asks) | Yes | Yes | Yes | Yes | Yes |
| Pull request labels | Yes | Yes | Yes | Yes, differently | Yes, differently |
| Link the pull request to its work item | Yes | Yes | Yes | Yes | Yes |
| Read review feedback (comments, verdicts) | Yes | Yes | Yes | Yes | Yes |
| Pull request outcome (merged, closed, reverted) for learning | Yes | Yes | Yes | Yes | Yes |
| Read the base branch's protection | Yes | Yes | Yes | Yes | Yes |
| Find the default branch | Yes | Yes | Yes | Yes | Yes |
| How a change to a pull request is noticed | Yes | Yes | Yes | Yes | Yes |
| Pagination of every list | Yes | Yes | Yes | Yes | Yes |
| Rate limits and retries | Yes | Yes | Yes | Yes | Yes |
| Self-hosted / on-premises edition | Yes | Yes | Yes | Not applicable | Yes |
| Authentication | Yes | Yes | Yes | Yes | Yes |
| Create a new, empty repository for a new product | Yes | Yes | Yes | Yes | Yes |
| Protect the default branch (pull request and review required) | Yes | Yes | Yes | Yes | Yes |
| Deployment environments with required reviewers | Yes | Yes | Yes | Yes, differently | Not applicable |
Where a service works differently, and why:
- Bitbucket Cloud, pull request labels: Written into the description. Bitbucket Cloud pull requests have no labels
- Bitbucket Cloud, self-hosted / on-premises edition: Bitbucket Cloud is a hosted service only. The self-hosted edition is Bitbucket Server / Data Center, its own row
- Bitbucket Cloud, deployment environments with required reviewers: The deployment environments are created; who may deploy is restricted in the repository's settings. Bitbucket Cloud has no required reviewers on a deployment environment
- Bitbucket Server / Data Center, open a draft pull request: draft: true on Data Center 8.18 and later; an older server ignores the flag, so the title starts "Draft: " and the description opens with a note that a person must review it before anyone merges it. Before 8.18 the server has no draft pull requests, so it cannot stop a merge itself; both marks stay on every update and go when the project takes the pull request out of draft
- Bitbucket Server / Data Center, pull request labels: Written into the description. Bitbucket Server pull requests have no labels
- Bitbucket Server / Data Center, deployment environments with required reviewers: Bitbucket Server has no deployment environments. Deployments belong to the CI server that runs them, which Yavaren does not start
Code agents
| Claude Code | GitHub Copilot CLI | OpenAI Codex CLI | Gemini CLI | Aider | |
|---|---|---|---|---|---|
| Credential (the only secret the CLI receives) | Yes | Yes | Yes | Yes | Yes |
| Runs without asking anyone | Yes | Yes | Yes | Yes | Yes |
| Model selection | Yes | Yes | Yes | Yes | Yes |
| Time limit | Yes | Yes | Yes | Yes | Yes |
| Runs in the sealed environment | Yes | Yes | Yes | Yes | Yes |
| How the prompt (with the stack and quality blocks) arrives | Yes | Yes | Yes | Yes | Yes |
| Reading its answer (review verdict, plans) | Yes | Yes | Yes | Yes | Yes |
| Tokens and cost | Yes | Yes, differently | Yes | Yes | Yes |
| Read-only mode for analysis (brief, features) | Yes | Yes | Yes | Yes | Yes |
Where a service works differently, and why:
- GitHub Copilot CLI, tokens and cost: Not reported by this CLI in a non-interactive run; the job's own duration is recorded. GitHub Copilot CLI prints no token or cost figures in silent, non-interactive mode
CI systems (deploying a new product)
| GitHub Actions | GitLab CI/CD | Azure Pipelines | Bitbucket Pipelines | |
|---|---|---|---|---|
| Start a deployment of one environment, after a named approver approved it | Yes | Yes | Yes | Yes |
| Follow the run to its end | Yes | Yes | Yes | Yes |
| Name the step that failed | Yes | Yes | Yes | Yes |
| Report the deployed address | Yes | Yes | Yes, differently | Yes, differently |
| The CI system's own approval of a deployment | Yes | Yes | Yes | Yes, differently |
| A short-lived identity token for the cloud (no stored cloud key) | Yes | Yes | Yes | Yes |
Where a service works differently, and why:
- Azure Pipelines, report the deployed address: The address given for the environment in the plan. Azure Pipelines environments carry no address to read
- Bitbucket Pipelines, report the deployed address: The address given for the environment in the plan. Bitbucket deployment environments carry no address to read
- Bitbucket Pipelines, the ci system's own approval of a deployment: Who may deploy is restricted on the deployment environment. Bitbucket has no approval of a deployment; Yavaren's named approvers are the approval