Timeline for Should composer.lock be committed to version control?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14 at 5:08 | comment | added | Luis Mauricio | @PierredeLESPINAY Under no normal circumstances you should update dependencies in production unless it comes from a tested preprod environment. Also, production should not have the hability to push to the repo as they should be as lean as possible and with a possible attack in mind, if an attacker gets a hold on one server and pushes changes, can then do an small ddos to pop more servers and "update" other servers with his code. Real attackers are not looking to drop your servers, but control them. | |
| Oct 28, 2019 at 19:04 | comment | added | ToolmakerSteve |
@Radu - If using composer, you are doing composer install at some step of your release cycle, right? My situation is use of docker containers and CircleCI (e.g. build/deploy to Amazon AWS). I don't see how one would accomplish this with no composer install. For the same reason that when there are multiple developer machines, composer install is a recommended step after anyone has changed composer.lock. What alternative is there?
|
|
| Mar 22, 2019 at 15:43 | comment | added | Radu |
@Seldaek I don't know if composer install should be part of the build/deploy procedure on production (or any remote environment to be honest). I personally prefer deploying the code package after it has been previously "prepared".
|
|
| May 2, 2016 at 7:39 | review | Suggested edits | |||
| May 2, 2016 at 8:30 | |||||
| Dec 23, 2013 at 12:31 | comment | added | Joaquín L. Robles | "In production you should not update your dependencies" should be written in all caps | |
| Oct 15, 2012 at 13:58 | vote | accept | Pierre de LESPINAY | ||
| Oct 15, 2012 at 13:54 | comment | added | Seldaek |
In production you should not update your dependencies, you should run composer install which will read from the lock file and not change anything.
|
|
| Oct 15, 2012 at 13:48 | comment | added | meza | If the composer.lock gets modified, you need to push the modifications back to the repository. If you want to tie the software to given versions of the libraries, then do so explicitly in the configuration. That way the lock will never change. Think of the lock file as an indicator of a dependency management issue which needs to be resolved one way or the other. | |
| Oct 15, 2012 at 13:45 | comment | added | Pierre de LESPINAY | Ok but imagine if I update the libraries from the production environment, composer.lock will be overwritten so a next pull from the production will ask me to merge this file... | |
| Oct 15, 2012 at 13:39 | history | answered | meza | CC BY-SA 3.0 |