digger icon indicating copy to clipboard operation
digger copied to clipboard

Digger CLI - uncaught exception - probably project name parsing

Open chvima opened this issue 1 year ago • 1 comments

v0.3.21 using orchestrator, self hosted digger, self hosted runners

Exception:

Using GitHub.
GitHub context parsed successfully
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0x18ad405]

goroutine 1 [running]:
main.gitHubCI({0x24c51b0, 0xc000128478}, {0x24c4ee0, 0xc000b1a360}, {0x24c4f10, 0xc000adbb60}, {0x24b2ae0?, 0xc0001a7068})
	/home/runner/work/digger/digger/cli/cmd/digger/main.go:132 +0xcc5
main.main()
	/home/runner/work/digger/digger/cli/cmd/digger/main.go:852 +0xa5c

Expected:

Using GitHub.
GitHub context parsed successfully
DEBUG: passing the following input policy: map[action:digger plan approvals:[] organisation:MYORG planPolicyViolations:[] project:accounts#shared-services#rds#dev teams:[DevOps] user:chvima] ||| text: package digger
...

To replicate: Configure digger project with "/" in name.

Example of the inputs sent to github action:

    "event": {
      "inputs": {
        "comment_id": "1934005920",
        "id": "qzbCiteW6KQ7JTNu",
        "job": "{\"projectName\":\"accounts/shared-services#rds#dev\",\"projectDir\":\"accounts/shared-services/rds/dev\",\"projectWorkspace\":\"default\",\"terragrunt\":false,\"commands\":[\"digger plan\"],\"applyStage\":{\"steps\":[{\"action\":\"init\",\"extraArgs\":[]},{\"action\":\"apply\",\"extraArgs\":[]}]},\"planStage\":{\"steps\":[{\"action\":\"init\",\"extraArgs\":[]},{\"action\":\"plan\",\"extraArgs\":[]}]},\"pullRequestNumber\":1591,\"eventName\":\"pull_request\",\"requestedBy\":\"chvima\",\"namespace\":\"MYORG/MYREPO\",\"stateEnvVars\":{},\"commandEnvVars\":{}}"

Not a breaking bug, the workaround for users: do not use "/" in project name, but still this should be either fixed or the exception properly caught.

chvima avatar Feb 08 '24 13:02 chvima

@chvima thanks for filing! ooh yeah interesting, seems that we are not catching this case correctly. I believe we should probably base64 or jwt the whole input as a single string passed to the job in one go to minimise the amount of errors that could be caused

motatoes avatar Feb 08 '24 14:02 motatoes