Pipeline fails with standard_init_linux.go:219: exec user process caused: argument list too long

Summary

I've a setup with 2 projects, one project for the developers containing the application (in this case a wordpress site), and one project with the deployment scripts. There are push and tag_push webhooks configured within the application project, to trigger the deploy project. This works fine during my tests, but I did some testing with only one or two files changed.

The developer pushed the whole application to the repo and the deploy pipeline failed with the message "standard_init_linux.go:219: exec user process caused: argument list too long"

Steps to reproduce

Add a "large" number of files in a commit to a project with webhooks to another project in place.

Example Project

application project: https://gitlab.com/deployable-nl/test-project3 with commit: deployable-nl/test-project3@a738efa3 deploy project: https://gitlab.com/deployable-nl/test-project4 triggered pipeline: https://gitlab.com/deployable-nl/test-project4/-/jobs/1140443451

What is the current bug behavior?

Pipeline environment setup fails

What is the expected correct behavior?

Pipeline environment setup succeeds

Relevant logs and/or screenshots

Running with gitlab-runner 13.9.0-rc2 (69c049fd) on docker-auto-scale 0277ea0f feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true Resolving secrets 00:00 Preparing the "docker+machine" executor Using Docker executor with image ruby:2.5 ... Pulling docker image ruby:2.5 ... Using docker image sha256:1c11408dfbae2c541d530fe19a78214d61356970197094731a8f63b047056306 for ruby:2.5 with digest ruby@sha256:5faedcc31072eaf771514214bc6aeeafcc4a6d900703e55f6ff8ef4e3f97fc3b ... Preparing environment 00:03 standard_init_linux.go:190: exec user process caused "argument list too long" ERROR: Job failed (system failure): prepare environment: exit code 1. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information

Output of checks

This bug happens on GitLab.com

Possible fixes

Maybe remove the commit details from the TRIGGER_PAYLOAD environment file, so only commit hash exists. If you need the commit details (like changed/added/deleted files) you can fetch them via the API in your deploy scripts. This way the TRIGGER_PAYLOAD variable has a fixed size, instead of dynamic, depending on the number of changed/added/deleted files in a push event.