Segfault when invoking glab ci list

[matyasrichter]

Description

Expected Behavior vs Actual Behavior
Expected: not a segfault
Got: segfault

Possible Fix

Steps to Reproduce
glab ci list

Logs

$ glab ci list
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xbd10b1]

goroutine 1 [running]:
github.com/profclems/glab/commands/ci/ciutils.DisplayMultiplePipelines(0xc0000bc000, 0xc000468420, 0x1e, 0x2a, 0xc000029100, 0xe, 0x9, 0x0)
	/home/runner/work/glab/glab/commands/ci/ciutils/utils.go:33 +0x2c1
github.com/profclems/glab/commands/ci/list.NewCmdList.func1(0xc000380f00, 0x16a5a48, 0x0, 0x0, 0x0, 0x0)
	/home/runner/work/glab/glab/commands/ci/list/list.go:71 +0x529
github.com/spf13/cobra.(*Command).execute(0xc000380f00, 0x16a5a48, 0x0, 0x0, 0xc000380f00, 0x16a5a48)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:852 +0x453
github.com/spf13/cobra.(*Command).ExecuteC(0xc000244a00, 0xc00000e018, 0xd3, 0x2)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:960 +0x349
main.main()
	/home/runner/work/glab/glab/cmd/glab/main.go:139 +0x7ae

Your Environment
glab version 1.16.0 (2021-03-12), the gitlab-glab-bin package from AUR
5.10.30-1-MANJARO #1 SMP Wed Apr 14 08:07:27 UTC 2021 x86_64 GNU/Linux

This only seems to happen on one of my projects. The project is on a self-hosted Gitlab instance, GitLab Community Edition 11.8.10. I'm not sure what my options are to provide more details, but I'll be happy to do so, just tell me how.

[profclems]

Thanks for opening this issue @matyasrichter.

I can't seem to reproduce this issue. Pls provide answers to the ff:

1. does the same error occur when you run gl ci list on another repo on the same instance?
2. does the repo in question have a gitlab-ci.yml?

[matyasrichter]

Yes, the repo does have a gitlab-ci.yml file. I've tried running the command on a different CI-enabled repo on the same instance, ran into the same issue. Other CI-related commands, like glab ci view, work fine on both.
Running on a third repo, which does not have a gitlab-ci.yml, produces the expected output:

$ glab ci list
No pipelines available on repo/path
No Pipelines available on repo/path

[zemzale]

TLDR: I think the issue is with the API version of GitLab, and we expecting fields that are not there.

From the docs, it seems that this field has only shown up in 12.xx versions, but I would feel better if we can check this before confirm that it's indeed the issue here.

Explantion

We list pipelines here:

glab/commands/ci/list/list.go

Line 61 in 8834968

pipes, err := api.ListProjectPipelines(apiClient, repo.FullName(), l)

which calls this API https://docs.gitlab.com/ce/api/pipelines.html#list-project-pipelines
Then we panic at

glab/commands/ci/ciutils/utils.go

Line 33 in 8834968

duration := utils.TimeToPrettyTimeAgo(*pipeline.CreatedAt)

which leads me to believe that the problem is pipeline.CreatedAt being null which leads to runtime panic because we can't dereference null pointer.

If we look at the API docs on the older version https://docs.gitlab.com/11.11/ee/api/pipelines.html#list-project-pipelines we can see that the response doesn't have a created_at field

[
  {
    "id": 47,
    "status": "pending",
    "ref": "new-pipeline",
    "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
    "web_url": "https://example.com/foo/bar/pipelines/47"
  },
  {
    "id": 48,
    "status": "pending",
    "ref": "new-pipeline",
    "sha": "eb94b618fb5865b26e80fdd8ae531b7a63ad851a",
    "web_url": "https://example.com/foo/bar/pipelines/48"
  }
]

Confirmation

We can easily confirm this theory by using the glab api command.

Could you @matyasrichter call glab api /projects/:fullpath/pipelines command from any of these projects that fail with this command? For newer versions the response should be something like this:

[
  {
    "id": 260268374,
    "project_id": 17660397,
    "sha": "0b8e76a313766e04eff7f0ba559f9e86681ba396",
    "ref": "test-repo-push-not-pushed",
    "status": "success",
    "created_at": "2021-02-23T07:49:53.196Z",
    "updated_at": "2021-02-23T07:51:09.708Z",
    "web_url": "https://gitlab.com/zemzale/project/-/pipelines/260268374"
  },
  ...
]

If your response doesn't contain the created_at field in the pipeline body then that indeed is gonna be the issue here.

[matyasrichter]

You're not wrong,@zemzale. The output looks like this:

[
  {
    "id": 123456,
    "sha": "d8a03e70f7d35bb464459d4e247925e23409d6aa",
    "ref": "some-ref",
    "status": "success",
    "web_url": "https://gitlab-instance.com/project/path/pipelines/123456"
  },
  ...
]

[zemzale]

Okay then. I will try to fix this somewhat soon.

But as always everyone is more then welcomed to create PRs issues.