Fixing composer config http-basic... is not defined in GitLab CI

[Synchro]

I'm using Laravel Nova. Since it's distributed under a commercial license, it requires auth during installation, and their docs show how to do this using the http-basic option in composer to allow it to run in my gitlab.com CI.

This all works fine in PHP 8.1, however, after updating the CI environment to PHP 8.2 and composer 2.5, it fails:

$ composer config http-basic.nova.laravel.com ${NOVA_USERNAME} ${NOVA_PASSWORD}
[32](https://gitlab.com/example/example-api/-/jobs/3514022179#L32)In ConfigCommand.php line 291:
[33](https://gitlab.com/example/example-api/-/jobs/3514022179#L33)                                               
[34](https://gitlab.com/example/example-api/-/jobs/3514022179#L34)  http-basic.nova.laravel.com is not defined.

I was mystified by this because all else had remained unchanged.

This command defines the http-basic.nova.laravel.com property, so complaining that it's not defined seems nonsensical. However, if the variables are not defined at all, they won't appear in the command, and it will effectively become:

composer config http-basic.nova.laravel.com

which is asking for a config value rather than setting one, and this explains the error. But why would these vars not be set when they were working fine before?

So I went and checked the config in GitLab, and noticed that I had originally marked these env vars as protected, which in GitLab means that these variables are only set for branches that are also protected. But I had created a new branch for testing PHP 8.2, which was not protected, so would not receive these variables.

Either unprotecting the vars or protecting the branch that's running in CI solves the problem.

So if you see error this in GitLab CI, check your env var visibility or branch protection state.

[zheliazkov]

The same issue here but with another Versioning/CI/CD platform - GitHub.
The vars/secrets visibility in the platforms was the issue too but the real problem is that this message is confusing us.

We should fix that.

[stof]

As there is no quotes around the bash variable, if that variable is empty (due to not being defined), the command being run will be composer config http-basic.nova.laravel.com which is a command reading the config, not defining it.

There is no way composer can warn you here. the command being run is a valid one, but for a different use case than your own.
The issue is that your command does not follow the Bash best practices and so you get hit by the confusing behavior that triggered the definition of those best practices.

composer config http-basic.nova.laravel.com "${NOVA_USERNAME}" "${NOVA_PASSWORD}"

With this command instead, the command being run when the variables are empty/undefined will be composer config http-basic.nova.laravel.com "" "", and so composer config will receive 3 arguments instead of 1, knowing that the command is run in write mode (whether it reports an empty username as an error or accepts it is a separate topic)

[zheliazkov]

Logical... stupid proposal.
Thanks for the explaination @stof.

[fredden]

You may also like to run set -u to treat undefined variables like this as an error instead of silently substituting an empty string in their place. For bash scripts that I write, the standard first line after the shebang is set -eu -o pipefail. https://linuxcommand.org/lc3_man_pages/seth.html

[zheliazkov]

@fredden it is a good option and info but in my case there is always a defined variable (empty or not).

I'm more concerned about the security aspect as mentioned here - @stof @fredden what would you suggest me as best practice in GitHub / GitHub Actions and overall?

[GromNaN]

Instead of running a command in your CI job, you can set the COMPOSER_AUTH variable in your Project settings.

[zheliazkov]

In my case i'm using GitHub Actions and passing non-problematic nova token with Dependabot only access for Laravel testing and currently assigning and using it (quoted) as env variable in the composer config step in a private repo, just for the nova repo auth.

Tried to add another step that has exported env vars as output and seems that it is masked as follows:

declare -x NOVA_EMAIL="***"
declare -x NOVA_LICENSE_KEY="***"

What do you think and what are the pros and cons for choosing either solution?

[GromNaN]

If you could define env var outside of the repository, using COMPOSER_AUTH would allow to set the credentials without any change in your CI actions. That what I did for our company satis, so we didn't have to modify 200 projects when we migrated from http to https.

[zheliazkov]

Thanks. As I understand in my case it can combine different repo auth's instead of multiple times running composer config but I need to use env var in the actions for sure (or I think so).

I'm concerned more about the security (no matter my repo is private) - currently there is a way someone with access to edit the GitHub workflow and to access some of the secrets/vars in a pull request for example :/ Not sure is there a way to make it more secure and will be glad to hear your professional opinion.