Support creating project variables

[profclems]

Describe the feature or problem you'd like to solve

It will be nice if glab provides support for creating project variables. Currently, users have to switch over to the GitLab web UI to create project variables

Propose a Solution
Provide variable create command for creating project variables.
Should have the format glab variable create <key> <value> [flag].

new and set can be used as aliases for create so glab variable set <key> <value> [flag] and glab variable set <key> <value> [flag] will be accepted.

Below are the parameters required by the endpoint and the suggested flags for glab

Attribute	Suggested Flag	Type	required	Description
key	none (must be passed as first argument)	string	yes	The key of a variable; must have no more than 255 characters; only A-Z, a-z, 0-9, and _ are allowed
value	none (must be passed as second argument)	string	yes	The value of a variable
variable_type	-t | --type	string	no	The type of a variable. Available types are: env_var (default) and file
protected	-p | --protected	boolean	no	Whether the variable is protected
masked	-m | --masked	boolean	no	Whether the variable is masked
environment_scope	-s | --scope	string	no	The environment_scope of the variable

Additional context

https://docs.gitlab.com/ee/api/project_level_variables.html#create-variable

[zemzale]

I would favor this being a subcommand under pipeline.

• we wouldn't pollute the core commands
• variables are used for pipelines so they just logically belong there (they are under CI/CD setting in the WEB UI too)

[profclems]

Makes sense but we are trying to avoid nested commands.

variable command will have other subcommands like create | set, get, list and delete | remove.

Putting it under ci will follow this format glab <command> <subcommand> <nested-subcommand>

glab ci variable [set | get | list | remove]

instead of simple glab <command> <subcommand>:

glab variable [set | get | list | remove]

[zemzale]

If we are just avoiding nesting commands as a whole then that makes sense.

[maxice8]

Is there a reason to avoid nested commands?

[profclems]

We are trying to have a format that will be predictable for users even if they don't read the docs. Users hardly read docs anyway