// the take
A Ruby client and CLI for the GitLab REST API (v4), wrapping nearly every endpoint GitLab exposes - projects, groups, merge requests, pipelines, epics, packages, container registry, and more. It's for Ruby shops scripting GitLab automation (CI jobs, migrations, internal tooling) or anyone who wants a quick terminal command instead of hand-rolling curl calls against GitLab's API.
Endpoint coverage is close to total - each resource (merge trains, epics, deploy tokens, registry, etc.) gets its own client module, so you're rarely stuck writing raw HTTP calls for something GitLab supports. Pagination is handled for you via auto_paginate/has_next_page?/next_page instead of making you parse GitLab's Link headers by hand. The same codebase works as a library, a one-shot CLI command, or an interactive shell, covering both scripted automation and quick ad hoc lookups. HTTParty config exposes the knobs that actually matter for self-hosted instances - proxy, SSL verify, custom headers, read timeout.
REST-only against API v4 - GitLab has been pushing newer features (epics relations, some CI/CD data) toward GraphQL-only, and this gem has no path to them. No built-in retry or backoff for transient failures or GitLab's own rate limiting, so bulk operations against a busy instance need you to wrap calls yourself. ObjectifiedHash is a loose runtime wrapper around whatever JSON comes back, not a typed/validated model, so a renamed or missing field from GitLab's side just turns into a silent nil instead of a loud error. The CLI's way of passing complex params is a raw YAML hash string on the command line, which is awkward to script reliably and a rough edge if that input path ever touches anything untrusted.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →