8000 Environment variables (ENV) for passing secrets to composer.json? · Issue #6081 · composer/composer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Environment variables (ENV) for passing secrets to composer.json? #6081

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
C-Duv opened this issue Jan 17, 2017 · 8 comments
Closed

Environment variables (ENV) for passing secrets to composer.json? #6081

C-Duv opened this issue Jan 17, 2017 · 8 comments

Comments

@C-Duv
Copy link
C-Duv commented Jan 17, 2017

I wonder if it would be useful (I ran into a use case where yes, it is) to pass repositories' credentials:

In the following composer.json, :

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://${REPO_USER}:${REPO_PASSWD}@repo.example.org"
        }
    ]
}

Running the following command would make Composer replace ${REPO_USER} and ${REPO_PASSWD} with the provided credentials when contacting repo.example.org

REPO_USER=extremely REPO_PASSWD=secret composer install

This would avoid storing secrets into composer.json and would ease Continuous Integration, Dockerification, etc.

My initial thought was to make environment variables interpreted in composer.json but according to few GitHub issues I stumbled upon, this will not happens to avoid making Composer too complex.
Maybe an intermediate fix could be done for credentials (such as, supporting a special environment variable syntax for repositories' credentials)?

A workaround is to create the auth.json file (as per the documentation but it's less direct and writes passwords to disk.
@stof
Copy link
Contributor
stof commented Jan 17, 2017 •
edited
Loading

IMO, a better solution is to integrate an environment feature in the credentials system only.

Allowing env variables anywhere in composer.json becomes a nightmare, because it means that different values of the env variables could require invalidating the composer.lock (imagine you use the env var for the full repository URL. A different URL may have different packages)

@C-Duv
Copy link
Author
C-Duv commented Jan 17, 2017

My thoughts exactly: env vars for credentials only is simpler and would not break too much things.
Note that it should support multiple credentials and repo.

Example:

composer.json:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://repo1.example.org"
        },
        {
            "type": "composer",
            "url": "https://repo2.example.org"
        },
    ]
}

SATIS_REPSAUTH="repo1.example.org:extremely:secret1\nrepo2.example.org:simple:secret2" \
    composer install

# Or:

SATIS_REPSAUTH_repo1_example_org="extremely:secret1" \
SATIS_REPSAUTH_repo2_example_org="simple:secret2" \
    composer install

@Seldaek
Copy link
Member
Seldaek commented Jan 22, 2017

COMPOSER_AUTH lets you store the auth.json in the env var actually.. https://getcomposer.org/doc/03-cli.md#composer-auth

@Seldaek Seldaek closed this as completed Jan 22, 2017
@TheCelavi
Copy link

May I ask for revising this request again, seams that there are some more use-cases here where it can be useful, per example, from: https://getcomposer.org/doc/06-config.md

  1. optimize-autoloader -> We could have variable that denotes if instance of app is in prod or dev mode (Symfony, someone?)
  2. cache-dir (cache dirs in general) -> I like this one much! On server, we can have multiple PHP docker containers with Composer installed on it. For each container, we can mount and configure same host directory to be shared in order to benefit from same cache. However, it must be configurable path if we intend to share, per example, a docker-compose.yml file on various OSes... (Mac, Linux, Windows).

Thanks!

@Seldaek
Copy link
Member
Seldaek commented May 31, 2018

For 1. we already have CLI flags, I don't see what an env var gains you there really, this stuff has to be in scripts anyway.

For 2. the cache dir is configurable via COMPOSER_CACHE_DIR already.
-->
@TheCelavi
Copy link

  1. I know, idea is that value is provided via .env file, because we use those for configuring if we are, among other things, in prod or dev environment. There is, of course, a CLI flag for this, but this is just a matter of convenience, a DX, if we have to write a deploy script that checks env var, and then builds a command accordingly - or library can handle env vars so we dont have to write a script.

  2. Yes, idea is to provide value with env var from .env file, so composer.json may be configurable. Fixing cache dir in composer.json means that all systems must use same cache dir, because, composer.json is part of source code repository.

@a-r-m-i-n
Copy link
a-r-m-i-n commented Mar 14, 2019 •
edited
Loading

Actually I have the case that I've got the same packages in two totally encapsulated environments. The transfer happens manually via Git.

So it would be very nice to have environment variables available provided by a .env file, for e.g. the VCS repo paths.

@greenbicycle
Copy link

I have a case where I pull in another repo into my project via composer. I have testing, staging and production branches. composer.json has to be different for each of these branches. So, currently, we have composer.json, composer-stage.json and composer-test.json all in the repository, but the only difference is one line. I am trying to figure out an easy way to consolidate them. If I could set an environment variable and then use it in composer.json that would work. Even if I could just set a variable on the command line, that would help too. Or use a global config variable. Maybe I am missing something obvious?

@SaberStrat SaberStrat mentioned this issue May 21, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@Seldaek @TheCelavi @stof @a-r-m-i-n @C-Duv @greenbicycle
0