Home

API Notes

Actual

let gl = GitLab::new(&hostname, &token);

// Requires passing a struct as option. The user builds the struct using the Builder Pattern.

// Listing projects
let projects = gl.projects(projects::Listing::new()).unwrap();
// Listing all projects (admin)
let projects = gl.projects_all(projects::all::Listing::new()).unwrap();
// Listing specific project id
let listing = projects::id::Listing::new(projects::id::ListingId::Id(10));
let projects = gl.project_id(listing).unwrap();

// Listing issues
let gl = GitLab::new(&hostname, &token);

let issues = gl.issues(issues::Listing::new()).unwrap();

let listing = issues::Listing::new().state(issues::ListingState::Opened).clone();
let opened_issues = gl.issues(listing).unwrap();

let listing = issues::Listing::new().state(issues::ListingState::Closed).clone();
let closed_issues = gl.issues(listing).unwrap();

let listing = issues::single::Listing::new(142, 739);
let issue = gl.issue(listing).unwrap();

let listing = issues::group::Listing::new(21).state(issues::ListingState::Closed).clone();
let group_issues = gl.group_issues(listing).unwrap();

let listing = issues::project::Listing::new(142).state(issues::ListingState::Closed).clone();
let project_issues = gl.project_issues(listing).unwrap();

Alternative 1

let gl = GitLab::new(&hostname, &token);

// FIXME: How to set the pagination?

// Builder pattern, committed with the list() method that performs the actual query.
// Pros: Follows GitLab API closely.
// Cons: Why do we always get the project after `merge_requests()`, `issues()`, etc. ?

// Get a specific merge request from its iid
let mr = gl.merge_requests().project(142).iid(418).list()
// List merge requests of project id 142 (mod.rs)
let mr = gl.merge_requests().project(142).list()
let mr = gl.merge_requests().project(142).state(...).iid(...).iid(...).list()
let mr = gl.merge_requests().project(142).state(...).iid(...).iid(...).order_by(...).sort(...).list()

// Issues
// List of all issues
let issues = gl.issues().list()
let issues = gl.issues().state(...).labels(...).order_by(...).sort(...).list()
// Single issue from a project
let issue = gl.issues().project(142).issue_id(5).list()
let issue = gl.issues().project(142).issue_iid(5).list()
// Project issues
let issues = gl.issues().project(142).state(...).labels(...).milestone(...).order_by(...).sort(...).list()
// Group issues
let issues = gl.issues().group(123).state(...).labels(...).milestone(...).order_by(...).sort(...).list()

// Projects
// List projects
let projects = gl.projects().list()
let projects = gl.projects().archived(...).visibility(...).order_by(...).sort(...).search(...).simple(...).list()
// List all projects (admin)
let projects = gl.projects().all().list()
let projects = gl.projects().all().archived(...).visibility(...).order_by(...).sort(...).search(...).list()
// Single project
let project = gl.projects().id(142).list()
// Search
let projects = gl.projects().search(...).list()
// Owned
let projects = gl.projects().owned().archived(...).visibility(...).order_by(...).sort(...).search(...).list()

Alternative 2

// Builder pattern, committed with the list() method that performs the actual query.
// Difference with 1): Instead of having `issues().project()`, `merge_requests().project()`, etc. invert to get
// `project().issues()`, `project().merge_requests()`, `project()`, etc.
// Pros:
//     Might be nicer for the user.
// Cons:
//     Different from GitLab API
//     The Project struct would need to implement the `issues()` and `merge_requests()` methods.