Cobra has some docs on generating autocompletion scripts for bash: https://github.com/spf13/cobra/blob/master/bash_completions.md

$ lab issue ls --verbose
#1 Issue title
        Issue link
        Issue description
        Assignees, Labels
#2 Issue title
        Issue link
        Issue description
        Assignees, Labels
...

Would love to have such an interface.

Sending large amounts of text to a gist was a long time favorite of mine to quickly share/document information with the rest of my team.

Having the equivalent for gitlab would be extremely handy.

Mimicking the API here would be ideal https://github.com/defunkt/gist

It's not uncommon for users to version control their dotfiles. A common file to version control is ~/.gitconfig.

Lab currently stores and retrieves a users access token from git config. Having my Gitlab access token stored in .gitconfig means that I can no longer version control this file, which it important to me as this file contains shared configuration for all of my projects on my system.

If I understand the documentation for Lab currently, I could add my access credentials to .git/config in each projects repository on my system, but this is a very tedious and cumbersome workaround to the issue.

github/hub Helps it's users in this case by storing access tokens in an application specific config file ~/.config/hub, which is a file that's less likely to be version controlled by users. I think Lab should use a similar solution, or at least provide it as an alternative credential store to the current git config system.

github/hubs implementation is here, if it helps.

#Most commands I try end with the same error, e.g.:

$ lab snippet list
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x13d6564]

goroutine 1 [running]:
github.com/zaquestion/lab/internal/gitlab.FindProject(0xc42001c18c, 0x13, 0xc42001c18c, 0x13, 0x0)
	/home/travis/gopath/src/github.com/zaquestion/lab/internal/gitlab/gitlab.go:98 +0x144
github.com/zaquestion/lab/cmd.glob..func23(0x1768f00, 0x178fbc8, 0x0, 0x0)
	/home/travis/gopath/src/github.com/zaquestion/lab/cmd/snippetList.go:48 +0x2fe
github.com/zaquestion/lab/vendor/github.com/spf13/cobra.(*Command).execute(0x1768f00, 0x178fbc8, 0x0, 0x0, 0x1768f00, 0x178fbc8)
	/home/travis/gopath/src/github.com/zaquestion/lab/vendor/github.com/spf13/cobra/command.go:702 +0x2c6
github.com/zaquestion/lab/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x1768ac0, 0x178fbc8, 0xc42017c020, 0xc4201ba000)
	/home/travis/gopath/src/github.com/zaquestion/lab/vendor/github.com/spf13/cobra/command.go:783 +0x30e
github.com/zaquestion/lab/vendor/github.com/spf13/cobra.(*Command).Execute(0x1768ac0, 0xc420080190, 0x2)
	/home/travis/gopath/src/github.com/zaquestion/lab/vendor/github.com/spf13/cobra/command.go:736 +0x2b
github.com/zaquestion/lab/cmd.Execute()
	/home/travis/gopath/src/github.com/zaquestion/lab/cmd/root.go:168 +0x2d7
main.main()
	/home/travis/gopath/src/github.com/zaquestion/lab/main.go:65 +0x499

My company runs GitLab on internal VPN with custom domain git.ccl, so my lab.hcl looks like this:

"core" = {
  "host" = "https://git.ccl"

  "token" = "<removed>"

  "user" = "<removed>"
}

The project where I try to run lab in has SSH remote (i.e.: origin [email protected]:group/project-name.git).

Version info:
macOS 10.13.3 (17D47)
git version 2.16.1
hub version 2.2.9
lab version 0.9.4 (via brew)

I am not sure if there is any flag or env variable to crank up verbosity. What other information can help you?

Similar to the lab mr command we want to be able to create and list issues for 1.0

Possible other subcommands

edit
comment

Flags:
-t, --track set checked out branch to track mr source remote, adds remote if needed

It probably makes since to detect if the mr source remote matches the forkedFromRemote, or forkRemote and to set tracking. Otherwise adding a new remote using the username scheme.

Example using issue

lab issue note [remote] <id> 

Add comment to an issue using provided message or $EDITOR

Flags
--message, -m stringSlice  msg to use for note

Ref: https://docs.gitlab.com/ce/api/notes.html

mislav/hub#1512 is definitely also an issue in lab.

I've run into 2 cases where lab permitted creating an MR when it really shouldn't have.

• source branch was not present on source remote (creates an MR with an unavailable branch)
• source branch is already up to day with target
  • observed when forgetting to commit changes and starting an MR

$ lab remote -v
Enter default GitLab host (default: https://gitlab.com): https://gitlab.example.net 
Enter default GitLab user: glen
Enter default GitLab token (scope: api ):
Create here: https://gitlab.com/profile/personal_access_tokens[]

should say: https://gitlab.example.net/profile/personal_access_tokens

also, there's some usability issue, the cursor is placed in [], i.e without newline. perhaps print that information before prompting user (swap two last lines)

also, the stty echo needs to be trurned off, not to show token when pasting it to terminal.

In Short

We can leverage the GitLab API to inform us if a repo is a fork or not and transparently support the "upstream" remote naming scheme.

Context

Currently a user clones a non-fork repo with the expectation that it will be setup as the "origin" remote. Later using lab fork to create a remote with their username. This is a somewhat newer approach to managing remotes.

Many people still use the strategy described and recommend here: https://help.github.com/articles/fork-a-repo/ and clone their personal fork as "origin". Later using git remote add upstream <repo> to configure their remote.

lab bias toward the former approach inline with how hub operates.

Proposed

If a solution can be reached that allows both approaches to transparently coexist without additional configuration by the user it would be highly considered. Otherwise the former approach will take precedent.

When cloning:

lab clone <personal-fork> 

1. lab clones repo (remote is "origin")
2. lab checks if repo is a fork
3. If so, lab adds the forked-from repo as a remote named "upstream"

When forking an unforked repo:
The bare lab fork command is not useful for "upstream" usecases, instead we'll optionally accept an argument for this case

lab fork <repo>

1. lab forks repo in GitLab
2. lab clones forked repo
3. lab adds forked-from repo as remote "upstream"

When creating merge requests:
lab always uses the tracked remote and current branch as the sourceRemote and soureceBranch, this will work the same for "upstream" cases. Currently lab defaults to and only support merge requests into "origin", to support "upstream" we will simply check for the existence of that remote and use that instead.

Finally
These changes should transparently support both world views and are able to be implemented cleanly within lab minimizing longer term maintenance costs for both approaches.

ref is getting fetched to head instead of branch name. So the branch doesn't point to the ref and the checkout is incorrect.

$ git mr checkout 587
From gitlab.com/phony
 * branch              refs/merge-requests/111/head -> FETCH_HEAD
   1234567..1234567             -> phony
Switched to branch 'phony'

It would be awesome, if a target could be specified during a merge request. I was thinking something like:

$ lab mr create --target play-1.2

After running lab mr and writing a message and exiting the editor I get the error:

2017/09/06 17:42:14 POST https:/URL_RETRACTED/api/v4/projects/PROJECT_ID_RETRACTED/merge_requests: 403 {message: 403 Forbidden}

Not sure what went wrong.

Possibly need to add more debug logging.

After aliasing git to lab, I noticed there are several inconsistencies to the help dialog. git --help, git help and git all return different output. git --help returns the output of lab --help, git help returns the output of hub --help and git returns the output of lab which is a combination of hub + lab.

All of these should be returning the same output. If hub isn't installed, lab and lab --help should both be returning the decorated git --help output. If it is installed, it should be decorating the hub --help output.

I recommend Unlicensed.

NOTICE: Description fully cannibalized by @zaquestion
Still debating if such a thing should be in lab, but could always move it into its own tool and be called by lab.
Support

• Running jobs
• Viewing jobs status (live)
• Viewing environments
  • Include re-deploying jobs

Also add lab ci lint command
Ref: https://docs.gitlab.com/ce/api/lint.html

Ref: https://gitlab.com/help/user/project/description_templates.md#setting-a-default-template-for-issues-and-merge-requests

Useful for creating templates to @mention other people you work with on new issues or MRs.

Need to find another place to store the temporary file lab creates when outside of a git repo and creating a personal snippet.

Expected behavior is to get the commits between the current branch and origin/master.

Saw this locally after fetching origin/master (but not merging into master), doing some changes and opening an MR. After checking out master and merging origin/master I reopened the MR and saw the correct list of commits.

I remembered that lab can checkout MR's and could list them as well.

Attempted lab mr ls. Which did not work. Though it did print out a nice help message which told me lab mr list had the desired functionality.

Thoughts on aliasing lab mr ls to lab mr list?

I would be happy to submit a PR if the feature sounds good.

When cloning with

lab clone [email protected]:lab-testing/test # this is a forked remote

Lab doesn't recognize the url and does a regular clone. Lab fails to look up the project and the upstream remote doesn't get added

Instead a new remote pointing to the fork gets added.
actual

origin [email protected]:lab-testing/test
lab-testing [email protected]:lab-testing/test

expected

origin [email protected]:lab-testing/test
upstream [email protected]:zaquestion/test

Generally I tend to submit links to my team with the URL provided by the merge-request tool, but append /diffs to the end.

It'd be nice to have it automatically appear that way based on the user's config file.

I get:

https://gitlab.com/example/my_project/merge_requests/100

I'd like

https://gitlab.com/example/my_project/merge_requests/100/diffs

Versions Impacted: 0.9.1, 0.9.2
Commands Impacted: lab mr create, lab issue create

Example using issue

lab issue browse [remote] <id>

lab issue browse # open gitlab issues in browser
lab issue browse 1 # open gitlab issue 1 in browser

Use --porcelain for commands where it makes sense.

git help status
...
       --porcelain
           Give the output in an easy-to-parse format for
           scripts. This is similar to the short output, but
           will remain stable across Git versions and
           regardless of user configuration. See below for
           details.

git help show

           porcelain
               Use a special line-based format intended for
               script consumption. Added/removed/unchanged
               runs are printed in the usual unified diff
               format, starting with a +/-/` ` character at
               the beginning of the line and extending to the
               end of the line. Newlines in the input are
               represented by a tilde ~ on a line of its own.

git help log

           porcelain
               Use a special line-based format intended for
               script consumption. Added/removed/unchanged
               runs are printed in the usual unified diff
               format, starting with a +/-/` ` character at
               the beginning of the line and extending to the
               end of the line. Newlines in the input are
               represented by a tilde ~ on a line of its own.

Help for command

lab mr note [remote] <id> 

Add comment to an mr using provided message or in $EDITOR

Operates on the checked out or provided merge request. Notes can be added to a specific line or to the merge request itself. Notes on the same line are appended to the same thread.

Flags
--message, -m stringSlice  msg to use for note
--line, -l                 Line to add comment
--right                    Add comment on new code
--left                     Add comment on existing code

Ref: https://docs.gitlab.com/ce/api/notes.html#merge-requests

Wondering if this should be a edit sub command or a flag --amend (like git)

Want to support setting/updating properties without having to edit the message. The flag approach would make sense to use --no-edit. Not sure the best choice for the sub command route...

That said, leaning towards the sub command to be consistent with other commands, and optionally support --amend as the flag off the parent command.

Saw an error today on a new installation of lab, on a macbook, where lab fork successfully created the fork, set the remote, but failed to fetch insisting that the fork/remote didn't exist.

Show changes annotated with comments

Flags:

 --ours, --left       Show only left hand side of diff
 --theirs, --right     Show only right hand side of diff
 --only                   Show only diff, removing notes

I am kind of lost.

I cloned a self-hosted repo on gitlab and I am trying to create a merge request or list all merge requests, but I am getting:

[dpetrov@macbook-pro /tmp/apps (master)]$ lab mr list
2018/03/06 22:40:58 mrList.go:38: gitlab project not found

Is there something that i am missing?

Thanks

On ubuntu 17.10 with go version go1.9.1 linux/amd64. running the install script gets:

./install.sh: 4: ./install.sh: [[: not found
+ go get -u -d github.com/zaquestion/lab
+ cd /src/github.com/zaquestion/lab
./install.sh: 9: cd: can't cd to /src/github.com/zaquestion/lab

I'm not really a gopher so I don't get why is searching for source files in that path.
How do I get around this to install lab?

somewhat related PD: Is there a way to provide linux binaries?

On branch issues/35, pushed to gitlab:

> lab merge-request
2017/12/11 08:56:36 aborting MR, branch not present on remote: origin

Any ideas?

What was expected?

When running git clone without specifying a url, I get a help message:

$ git clone
You must specify a repository to clone.

usage: git clone [<options>] [--] <repo> [<dir>]

    -v, --verbose         be more verbose
    -q, --quiet           be more quiet
...
...

What happened instead?

When I ran lab clone without a url, lab panic'd:

$ lab clone
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x58350f]

goroutine 1 [running]:
github.com/zaquestion/lab/vendor/github.com/spf13/cobra.(*Command).ParseFlags(0x9c6a40, 0xc42000c310, 0x1, 0x1, 0x9c6a40, 0x9e69a0)
	/home/leland/projects/go-projects/src/github.com/zaquestion/lab/vendor/github.com/spf13/cobra/command.go:1267 +0x3f
github.com/zaquestion/lab/cmd.Execute()
	/home/leland/projects/go-projects/src/github.com/zaquestion/lab/cmd/root.go:81 +0x122
main.main()
	/home/leland/projects/go-projects/src/github.com/zaquestion/lab/main.go:6 +0x20

How might this be fixed?

From what I can see in the cmd/root.go file, the problem is in an unchecked slice of the os.Args slice on line 81. Directly above that line is a somewhat confusing comment which may or may not have anything to do with this issue, I had a hard time understanding it, though it may be of some use to whoever choses to fix this.

The change would be to check if clone has been provided without any additional arguments/parameters, and if it has, to print a help message in some way. The printing of a help message could be done by dropping down to gits help message or by printing labs own custom help message.

lab seems to have issues if remote origin is of type http or https rather than ssh in the .git/config file.

To illustrate:

This works:

[remote "origin"]
	url = [email protected]:foo/bar.git
	fetch = +refs/heads/*:refs/remotes/origin/*

This does not work:

[remote "origin"]
	url = https://gitlab.com/foo/bar.git
	fetch = +refs/heads/*:refs/remotes/origin/*

Similar to: #78 expected outcome is the same

Use - for the title instead of opening an editor.

The editor workflow for writing title and description is confusing people even with comments indicating which is which. Instead take the approach other tools are using for github and default to -

$ lab issue list by-labels "bug, help wanted"

should list the issues based on labels. An addition to MRs by labels and assignees would be a better addition too.

Hi, I'd like to create a Homebrew formula for this project, but it seems there are no releases or tags, so I cannot point to a stable version. Do you think you could add tags as part of your release process? Thanks!