Inspiration
Development keeps moving after we leave our desks. A pipeline can fail while we are away, and an agent can propose a fix that still needs a person to inspect it. I wanted a useful way to follow that work from my phone: the actual project, commit, job, proposed change and result.
GitBack grew out of my MIT-licensed ISyCoFeedback work on bounded repair workflows and receipts. For this hackathon, I built the mobile GitLab experience and the post-code automation around it.
What it does
GitBack brings GitLab into four connected sections: Activity, Projects, Repairs and Account.
The installed iPhone app connects through GitLab OAuth with PKCE, lists accessible projects, loads pipelines and jobs, and displays bounded job-log excerpts locally. Screens retain the project, branch/ref, commit SHA and timestamps. A separate, labeled Synthetic Preview lets people explore example screens without querying GitLab.
The current native build also includes persistent light/dark/system appearance, a richer project view, optional api access, confirmation-gated CI retry/cancel controls, and personal GitLab preference/notification settings. The write operations have controlled API tests; they are not presented as completed live mutations in the current demonstration.
How GitLab Duo is used
The automation runs in GitLab through the Duo Agent Platform's Fix CI/CD Pipeline flow:
- A real boundary test fails on an isolated demonstration branch.
- The failed-pipeline trigger starts GitLab Duo.
- Duo proposes a merge request with a small data-only correction.
- CI and an independent, immutable-baseline verification provide separate evidence about the candidate.
- A person reviews the result and decides whether to merge.
This workflow has run against the public Showcase project. The recorded failure is pipeline 2979446909, the Duo workload is 2979453657, and the proposal is MR !3.
The candidate changed only demo/retry-policy.json. The independent verifier extracted the evaluator and original tests from the baseline commit and evaluated the candidate data against them. Its receipt records PASS with six original tests passing. A human subsequently merged the fix into the isolated demonstration branch.
The verifier is a scoped review control, not a claim of general security certification or a server-enforced protected-branch policy.
How we built it
The client uses Expo, React Native and TypeScript for native screens, plus React/Vite for the PWA. Shared modules implement OAuth, typed GitLab API access, account state and explicit operation targets. Native credentials use SecureStore; browser credentials remain in memory.
GitLab CI checks the web/native sources and the repair-policy verifier. EAS produces the native iPhone artifact, with a separate GitLab artifact-import path for the inspected build. The public web workspace is deployed through GitLab Pages.
Codex and Manus assisted development, implementation and review. GitLab Duo is the agent that performs the demonstrated repair workflow.
Challenges we ran into
Keeping OAuth connected across tabs and source changes took several iterations. Another challenge was making the polished Preview layout useful with real data, where an MR, diff or test result may genuinely be absent.
We also had to preserve the distinction between proposing a change, observing a successful job, independently checking a particular candidate SHA and recording a human decision. GitBack should identify the evidence it actually has.
Accomplishments that we're proud of
GitBack progressed from a visual prototype to an iPhone app that displays real account, project, pipeline, job and log data. The owner confirmed the latest delivered 1.3.1/build 10 update works on the phone.
The established test baseline includes 59 shared/native tests, 10 web tests and a controlled browser E2E covering OAuth, CI confirmations, Settings and Preview isolation. Those fixture results complement the device and GitLab-run evidence; each proves a different part of the system.
We also completed a real Duo proposal, independent candidate verification and human merge on the demonstration branch.
What we learned
A developer tool earns trust by keeping identity, permissions and evidence attached to each action. A proposed patch, a green pipeline and a reviewed merge are distinct events. Clear state and a small reproducible workflow are more useful than a dashboard filled with simulated progress.
What's next
The current increment is bringing the complete MR review journey into Repairs: a real MR inbox, versioned diffs, checks matched to the selected SHA, comments and a confirmation-gated review comment. This increment is still under implementation and review.
Approval and merge remain in GitLab. Final live write-operation acceptance, the updated native build, public-source integration and refreshed demonstration materials follow after this increment passes review.
Try it
Demo video status: The embedded video is an older ISyMotron placeholder. The final GitBack walkthrough has not been recorded yet and will replace it before the deadline.
- Public GitBack workspace
- Public GitLab source and pipeline history
- Original MIT-licensed ISyCoFeedback project
The public workspace can be explored without account credentials. Connected-account features require your own GitLab authorization. Synthetic examples remain labeled and separate from live evidence.
GitBack — your GitLab workspace, back in your pocket.
Built With
- expo.io
- gitlab
- gitlab-api
- gitlab-ci/cd
- gitlab-duo
- ios
- oauth-2.0
- pkce
- playwright
- python
- react
- react-native
- rest-api
- typescript
- vite
Log in or sign up for Devpost to join the conversation.