You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
_lab_ interacts with repositories on GitLab, including creating/editing merge requests, issues, milestones, snippets
30
+
and CI pipelines.
4
31
5
-
Lab wraps Git, making it simple to clone, fork, and interact with repositories on GitLab, including seamless workflows for creating merge requests, issues and snippets.
32
+
The development team has focused on keeping _lab_ a simple and intuitive command line interface for commands provided
33
+
in the [GitLab API](https://docs.gitlab.com/ee/api/api_resources.html). _lab_'s aim is to provide GitLab users an
34
+
experience similar to the GitLab WebUI with respect to errors and messages.
One can use _lab_ as a Git alias, integrating seamlessly to their Git workflow.
39
+
```
40
+
$ cat ~/.gitconfig
41
+
...
42
+
[alias]
43
+
lab = "!lab"
44
+
lab-i = "!lab issue"
45
+
li = "!lab issue"
46
+
47
+
$ git lab mr list
48
+
$ git lab-i close
49
+
$ git li create
12
50
```
13
51
14
-
# Inspiration
52
+
Also, _lab_ can be set as shell aliases:
15
53
16
-
The [hub](https://github.com/github/hub) tool made my life significantly easier and still does! lab is heavily inspired by hub and attempts to provide a similar feel.
54
+
```bash
55
+
alias mrlist="lab mr list"
56
+
```
17
57
18
58
# Installation
19
59
20
-
Dependencies
21
-
22
-
*`git`
60
+
In compilation-time, _lab_ depends only on other Go external modules, defined at go.mod. At runtime, _git_ is required
61
+
as many git commands are used by _lab_ to retrieve local repository information.
23
62
24
63
### Homebrew
25
64
```
@@ -43,28 +82,30 @@ apk add lab
43
82
```
44
83
45
84
### Bash
85
+
In case you don't want to install _lab_ using any of the above package managers you can use the Bash script available:
86
+
87
+
> :warning: The script will install _lab_ into `/usr/local/bin/`.
- If these variables are set, the config files will not be updated.
90
-
- For example to use gitlab.com do: `export LAB_CORE_HOST="https://gitlab.com"`
91
-
3. local configuration file in [Tom's Obvious, Minimal Language (TOML)](https://github.com/toml-lang/toml): `./lab.toml`;
92
-
- No other config files will be used as overrides if a local configuration file is specified
93
-
4. user-specific configuration file in TOML: `~/.config/lab/lab.toml`.
94
-
- An example of user-specfic configurations in lab.toml can be found below. As seen in the example file below, any command options specified by --help (for example 'lab mr show --help', or 'lab issue edit --help') can be set in the configuration file using TOML format.
122
+
### Fresh start
95
123
124
+
When _lab_ is executed for the first time, no suitable configuration found, it will prompt for your GitLab information.
125
+
For example:
126
+
127
+
```
128
+
$ lab
129
+
Enter default GitLab host (default: https://gitlab.com):
130
+
Enter default GitLab token:
96
131
```
132
+
133
+
These informations are going to be save it into `~/.config/lab/lab.toml` and won't be asked again.
134
+
In case multiple projects require different information (ie. _gitlab.com_ and a self-hosted GitLab service), using
135
+
different configuration files as explained in the section below.
136
+
137
+
### Configuration file
138
+
139
+
The most common option is to use _lab_ configuration files, which can be placed in different places in an hierarchical
140
+
style. The [Tom's Obvious, Minimal Language (TOML)](https://github.com/toml-lang/toml) is used for the configuration
141
+
file.
142
+
143
+
When a local configuration file is present (`./lab.toml`), no other configuration file will be checked, this will be
144
+
the only one used for looking up required information.
145
+
146
+
However, other two options are possible:
147
+
148
+
1. User-specific: `~/.config/lab/lab.toml`
149
+
2. Worktree-specific: `.git/lab/lab.toml`
150
+
151
+
These two files are merged before _lab_ runs, meaning that they're complementary to each other. One thing is important
152
+
to note though, options set in the worktree configuration file overrides (take precedence over) any value set in the
153
+
user-specific file.
154
+
155
+
An example of user-specific configurations can be found below. As seen in the example file below, any command options
156
+
specified by `--help` (for example `lab mr show --help`, or `lab issue edit --help`) can be set in the configuration
157
+
file using TOML format.
158
+
159
+
```toml
97
160
[core]
98
161
host = "https://gitlab.com"
99
162
token = "1223334444555556789K"
@@ -110,28 +173,23 @@ instance. There are several ways to provide this information to `lab`:
110
173
force-linebreak = true
111
174
```
112
175
113
-
5. work-tree configuration file in TOML: `.git/lab/lab.toml`. The values in
114
-
this file will override any values set in the user-specific configuration file.
176
+
### Local environment variables
115
177
116
-
If no suitable config values are found, `lab` will prompt for your GitLab
117
-
information and save it into `~/.config/lab/lab.toml`.
118
-
For example:
178
+
If running _lab_ locally, the variables `LAB_CORE_HOST` and `LAB_CORE_TOKEN` can be used, preventing configuration file
179
+
creation/update. For example to use _gitlab.com_ do:
119
180
```
120
-
$ lab
121
-
Enter default GitLab host (default: https://gitlab.com):
122
-
Enter default GitLab token:
181
+
export LAB_CORE_HOST="https://gitlab.com"
123
182
```
124
183
125
-
Command-specific flags can be set in the config files.
184
+
### CI environment variables
126
185
127
-
```
128
-
[mr_show]
129
-
comments = true # sets --comments on 'mr show' commands
186
+
The environment variables `CI_PROJECT_URL`, `CI_JOB_TOKEN` and `GITLAB_USER_LOGIN`, intended to be used in a CI
187
+
environment, can be set to prevent any configuration file creation/update. Also, any of these take precedence over all
188
+
other options.
130
189
131
-
```
132
190
# Completions
133
191
134
-
`lab` provides completions for [Bash], [Elvish], [Fish], [Oil], [Powershell], [Xonsh] and [Zsh].
192
+
_lab_ provides completions for [Bash], [Elvish], [Fish], [Oil], [Powershell], [Xonsh] and [Zsh].
135
193
Scripts can be directly sourced (though using pre-generated versions is recommended to avoid shell startup delay):
## What about [GLab](https://github.com/profclems/glab)?
220
+
#Contributing
163
221
164
-
Both [glab] and `lab` are open-source tools with the same goal of bringing GitLab to your command line and simplifying the developer workflow. In many ways `lab` is to [hub], what [glab] is to [gh].
222
+
We welcome all contributors and their contributions to _lab_! See the [contribution guide](CONTRIBUTING.md).
165
223
166
-
`lab` aims to feel familiar to a `git` user and leverages `git` to power many of it's commands. `glab` will feel more familiar to `gh` users and in turn is more interactive and likely more beginner friendly for that reason.
224
+
# What about [GLab](https://github.com/profclems/glab)?
167
225
226
+
Both [glab] and `lab` are open-source tools with the same goal of bringing GitLab to your command line and simplifying
227
+
the developer workflow. In many ways `lab` is to [hub], what [glab] is to [gh].
168
228
169
-
```
170
-
$ lab
171
-
Enter GitLab host (default: https://gitlab.com):
172
-
```
229
+
If you're looking for a tool like _hub_, less opinionated, that feels like using _git_ and allows you to interact with
230
+
GitLab then _lab_ is for you. However, if you're looking for a more opinionated tool intended to simplify your GitLab
0 commit comments