GitLab

Documentation

runGitLab :: GitLabServerConfig -> GitLab a -> IO a

runs a GitLab action.

Internally, this creates a single Manager, whichs keeps track of open connections for keep-alive and which is shared between multiple threads and requests.

An example of its use is:

projectsWithIssuesEnabled :: IO [Project]
projectsWithIssuesEnabled =
  runGitLabyConfig $ filter (issueEnabled . issues_enabled) <$> allProjects
  where
    myConfig = defaultGitLabServer
        { url = "https://gitlab.example.com"
        , token = "my_access_token" }
    issueEnabled Nothing = False
    issueEnabled (Just b) = b

runGitLabPassPrompt :: GitLabServerConfig -> GitLab a -> IO a

The same as runGitLab, except that it prompts for a GitLab access token before running the GitLab action.

In this case you can just use defaultGitLabServer with no modification of the record field values, because these values will be asked for at runtime:

runGitLabPassPrompt defaultGitLabServer myGitLabProgram

runGitLabDbg :: GitLab a -> IO a

Only useful for testing GitLab actions that lift IO actions with liftIO. Cannot speak to a GitLab server. Only useful for the gitlab-haskell tests.

runGitLabWithManager :: Manager -> GitLabServerConfig -> GitLab a -> IO a

The same as runGitLab, except that it also takes a connection manager as an argument.

module GitLab.Types

module GitLab.API.Pipelines

module GitLab.API.Groups

module GitLab.API.Members

module GitLab.API.Commits

module GitLab.API.Projects

module GitLab.API.Users

module GitLab.API.Issues

module GitLab.API.Branches

module GitLab.API.Jobs

module GitLab.API.MergeRequests

module GitLab.API.Repositories

module GitLab.API.RepositoryFiles

module GitLab.API.Tags

module GitLab.API.Todos

module GitLab.API.Version

module GitLab.API.Notes

module GitLab.API.Boards

module GitLab.API.Discussions

module GitLab.SystemHooks.GitLabSystemHooks

module GitLab.SystemHooks.Types

module GitLab.SystemHooks.Rules