NARKOZ/gitlab

This system is a Ruby gem that provides a comprehensive client library for interacting with the GitLab API, covering resources such as projects, builds, branches, and container registries. It features a command-line interface and an interactive shell for direct usage, along with robust error handling, automatic pagination, and rate-limiting support. The library is designed for programmatic access, allowing developers to manage GitLab entities via Ruby code or CLI commands.

7 changes.

The project was initialized with core infrastructure, including Docker containerization, linting configuration, and dependency management. Significant effort focused on restructuring the library for Ruby 3 compatibility, introducing a new CLI and shell interface, and expanding client modules to cover a broad range of GitLab API endpoints.

5 changes.

This period focused on establishing the core infrastructure for the GitLab Ruby gem, including the creation of a command-line interface entry point and development convenience scripts. Significant work was also dedicated to implementing and testing header parsing utilities for efficient API pagination and total count handling.

A new executable script at exe/gitlab has been added to serve as the command-line interface entry point. It initializes the load path, requires the Gitlab::CLI module, and starts the CLI. Additionally, it includes a handler for the INT signal to ensure the application exits cleanly (with exit code 1) when interrupted.

exe · high confidence

New executable scripts have been added to the bin directory to streamline local development. The bin/setup script automates the installation of dependencies via Bundler and reminds users to configure the required GITLAB\_API\_ENDPOINT and GITLAB\_API\_PRIVATE\_TOKEN environment variables. Additionally, bin/console provides an interactive Pry environment with the application library pre-loaded, facilitating easier debugging and exploration of the codebase.

bin · high confidence

The repository has been initialized with core project files including a Gemspec, Rakefile, and README. A new Dockerfile and docker-compose.yml are provided to containerize the application using Ruby 3.2, alongside a .dockerignore to optimize builds. RuboCop linting is configured with specific plugins (performance, rspec, rake) and a target Ruby version of 3.2, supported by generated .rubocop.yml and .rubocop\_todo.yml files. The Rakefile now includes tasks for running specs and RuboCop checks.

(repo-wide) · high confidence

This release introduces a new command-line interface (CLI) and interactive shell for the GitLab Ruby gem, allowing users to run commands like \gitlab help\ or start an interactive session with tab completion and history support. It also significantly improves error handling by introducing a \ResponseError\ class that exposes HTTP status codes, response messages, and error codes, replacing the previous generic error classes. Additionally, the gem now supports automatic pagination with limits, respects HTTP 429 rate-limiting headers with retries, and allows configuring HTTParty options via environment variables.

lib/gitlab · high confidence

The client library adds new modules to expose GitLab API endpoints for access requests, application settings, avatars, award emojis, issue boards, branches, broadcast messages, build variables, builds, commits, and the container registry. Users can now manage project and group access requests, retrieve and edit application settings, look up user avatars, manage award emojis on issues and merge requests, create and edit issue boards, protect and create repository branches, manage broadcast messages, handle project and group build variables, interact with builds and their artifacts, perform commit operations like cherry-pick and revert, and manage container registry repositories and tags.

lib/gitlab/client · high confidence

Added two new classes in the lib/gitlab/headers module: PageLinks, which parses the 'Link' header to extract pagination URLs (first, prev, next, last), and Total, which parses the 'x-total' header to retrieve the total record count. These utilities enable more efficient handling of API responses by avoiding unnecessary requests to determine pagination boundaries or total item counts.

lib/gitlab/headers · high confidence

The library has been restructured to use standard gem-style requires instead of relative file paths, introducing new modules for handling HTTP headers (page links, total count) and response types (paginated, file responses). A new \http\_proxy\ method has been added to the main Gitlab module, allowing users to configure HTTP proxy settings for API requests. Additionally, the \actions\ method now exposes a list of available client methods while filtering out internal or low-level methods, and the module's delegation logic has been updated to use \respond\_to\_missing?\ for better compatibility with Ruby 3.

lib · high confidence

Added test coverage for GitLab Ruby gem core components; Added test coverage for GitLab client API methods; Added tests for GitLab headers parsing; Updated test suite to RSpec 3 syntax and refactored HTTP stub helpers.

This change introduces a new \package.json\ and \package-lock.json\ to add VitePress (v2.0.0-alpha.15) as a development dependency for building documentation, alongside a \Gemfile\ update that adds Rubocop-related gems (rubocop, rubocop-performance, rubocop-rspec, rubocop-rake) and Pry for development. The \gitlab.gemspec\ is updated to require Ruby 3.2+, adds metadata for Multi-Factor Authentication on RubyGems, and bumps the \httparty\ runtime dependency to version 0.20 while adding \base64\ and \readline\ as runtime dependencies.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• First survey — no prior run to compare against. CAI 63.

• Code Health 97
• Architecture 97
• Maturity 49
• Readiness 69
• Security 68

• 300 commits — 259 feature/other, 41 fixes

• lib/gitlab — 120 commits
• (repo) — 69 commits
• (root) — 52 commits
• spec/fixtures — 21 commits
• .github/workflows — 17 commits
• spec/gitlab — 15 commits
• .github/FUNDING.yml — 2 commits
• lib/gitlab.rb — 2 commits
• .github/stale.yml — 1 commit
• bin/console — 1 commit

• fix: Add fixes for rubocop; However, I disagree with the "too many lines" rule for the specs. To "fix" we had to make extremly long lines which is not as readable.
• fix: Add workaround to fix the CI build
• fix: Added missing methods and fixed existing ones with file download in job artifacts API
• fix: Fix 404 error when retrieving the issues a merge_request will close
• fix: Fix CI badge
• fix: Fix a deprecated input in workflow
• fix: Fix a rubocop offense
• fix: Fix availability of methods for project export API
• fix: Fix new rubocop offenses
• fix: Fix outdated options hash documentation for tree and commits methods (#526)
• fix: Fix rdoc for create_commit
• fix: Fix rubocop error
• fix: Fix rubocop offense
• fix: Fix rubocop offense
• fix: Fix rubocop offense
• fix: Fix rubocop offenses
• fix: Fix rubocop offenses
• fix: Fix rubocop offenses
• fix: Fix rubocop offenses
• fix: Fix rubocop offenses
• …and 280 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

NARKOZ/gitlab was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.