A merge request in GitLab is the mechanism that turns a branch into a proposal. It is not a Git operation—Git has no concept of a merge request. It is a GitLab feature that wraps the branch in a review workflow: discussion, pipeline verification, and a merge gate. The exam tests the lifecycle: how the…
A repository in GitLab is more than a Git directory. It is a project with a default branch, a set of permissions inherited from the namespace hierarchy, and a set of protected branches that enforce who can push and who can merge. The Git commands are the same as anywhere else—git clone, git checkout -b,…
GitLab supports two primary methods for authenticating Git operations and API requests: SSH keys and Personal Access Tokens (PATs). SSH keys are the preferred method for Git operations because they provide a secure, passwordless workflow after the initial setup. PATs are the mechanism for authenticating against the GitLab API, and they serve as the password…
GitLab organizes work through a three-tier namespace hierarchy: groups, subgroups, and projects. A project contains the repository, issues, merge requests, and CI/CD pipelines. A group is a container for projects and other groups. A subgroup is a group nested inside another group. The hierarchy is not cosmetic—it determines how permissions inherit, how visibility is enforced,…
GitLab began as an open-source project in 2011, started by a single commit with the goal of improving collaboration among team members . Over a decade later, it has evolved into an intelligent orchestration platform that brings development, security, and operations together into a single application . The core premise is simple but ambitious: instead…
Bun’s file system layer is not a wrapper around Node’s fs module. It is a set of native APIs—Bun.file() and Bun.write()—implemented in Zig and optimized for the runtime’s event loop. The BunFile object is a lazy reference: creating it does not read the file from disk. The data is loaded only when a method is…
The Bun.serve() API is the runtime’s built-in HTTP server. It is not a wrapper around Node’s http module, nor does it require an external framework like Express or Fastify. The server is powered by a fork of uWebSockets, written in C++ and Zig, and exposed through a JavaScript API that uses the standard Request and…
Bun ships with a native SQLite driver, and it is not a JavaScript wrapper around a WebAssembly module or a binding to a system library. The bun:sqlite module is implemented in Zig and linked directly into the runtime. This means there is no npm install sqlite3, no better-sqlite3 compilation step, and no native module incompatibility…
Bun’s runtime is built around a full transpiler, not a type-stripper. When you run a .ts, .tsx, or .jsx file with bun run, the engine reads the source, applies the JSX transform specified in tsconfig.json (or bunfig.toml), strips the TypeScript type annotations, and executes the resulting JavaScript directly . There is no separate tsc step,…
Bun’s execution layer is split into two distinct commands that serve different purposes. bun run executes scripts defined in package.json or runs source files directly. bunx executes binaries from npm packages, installing them temporarily if they are not already present. The distinction matters: bun run operates within the project’s context, while bunx operates at the…