So in my last blogpost I showed how to automatically create a PHAR-file using Travis-CI. It didn’t take long for a challenge to show up: Digitally sign the resulting PHAR-file.
I already did some work with encrypting and decrypting stuff for an individual automated deployment to a server a few months back. So signing stuff shouldn’t be that complicated I thought. Therefore: Challenge accepted!
I recently was asked whether JUnitDiff was available as a PHAR. Up to that point I hadn’t actually thought about it. But it made sense. The only thing I was sure about was that I didn’t want to have to think about it when doing a release. So the solution should fit nice into the build-chain.
A few weeks ago I updated our gitlab-installation to the glorious, shiny and new 8.12.6! Awesome new stuff! It had only one drawback. We couldn’t clone repos via HTTP(S) anymore.
It wasn’t that much of a drawback at the time but then we wanted to use the included CI-stuff. And that – you guessed it already – only works with cloning or fetching the repo via HTTP(S).
Continue reading Fixing issues with cloning via HTTPS on GitLab
The other day I wanted to have an automated deployment for a sideproject (callingallpapers.com) of mine. I wanted to be able to merge a PullRequest on github and have Travis-CI deploy the merged files via rsync after all tests succeed. Easy thing I thought, I can’t be the first one attempting that. Looked like I was at least the first one writing about it… Continue reading Automated deploy from travis-ci via ssh
Whether to commit a composer.lock-file to a repository or not seems to be a somewhat religious decision. Either you follow Raphael Dohms and commit your lock-file or you follow Marco Pivetta and you don’t.
But I think the truth is somewhat in between.
Recently I decided to create a badge for Badge Poser that shows whether the lock-file is commited or not. It’s something you can see easily from the repo but hey, it’s a fun project!
And instantly I stumbled over a commited lock-file! Because as it seems, commited composer.lock-files can be a blessing or a curse. What happened? I thought – as the project commited their composer.lock-file – it would be a good idea to run a composer install instead of a composer update. After all I should be left with a working installation after the install-command. That’s why we would commit the lock-file in the first place, isn’t it?
But as it turned out, the composer.lock-file was created some time ago with a now hopelessly outdated PHP-version. I have PHP 7 running on my machine, but the composer.lock-file obviously was created using something like PHP 5.3 or PHP 5.4. So instead of getting a running version of the project, I got composer yelling at me that it can’t resolve an installable version of my lock file. Hm.
So it looks like it’s dependent on the PHP-Version you are running whether the composer.lock can be used or has to be updated. Sadly there’s no hint that tells me which PHP-Version the file has been created with so I will have to test whether an install will work or not.
Entry the “config/platform”-parameter. It allows the creator of a package to specify what PHP-Version should be used to resolve the dependencies regardless of what the actual PHP-Version is. This might have the consequence of installing useless packages as installed packages might not work on the installed PHP-Version.
So one thing to have in mind when committing or receiving a composer.lock-file is, that it contains a set of dependencies, that was working for the committer but it might not work for the user as the environment might have changed to a point where the packages of the composer.lock-file might not be usable anymore. Consider a locked Version of phpunit/phpunit:4.8 because the file was created using PHP 5.5 and you are running PHP 7.
The second thing that came to my mind was that the lock-file might or might not contain the dev-requirements. So when you are developing a lib you’d want other developers to have the same versions of your dev-tools so it’s a good idea to have them in the lock file. And when you are developing a web-project (website of a certain extend) you might want to use the lock-file to automatically deploy the libs you where testing agains. But as it’s for deployment you’d create the lock-file without the dev-dependencies. That will then leave other developers without the dev-dependencies, so they will have to run a composer update (because composer install will tell you that you should either run composer install --no-dev or composer update) anyway.
And also when you do automated testing against the lowest,locked,latest-strategy you might run into issues with locked packages not being able to run on the current platform even though they are installed without an issue. Have a look for example at https://travis-ci.org/heiglandreas/composerlocktest/jobs/133745846. The test fails due to PHPUnit being installed in the wrong version due to that version being locked in the composer.lock-file
Be careful when you commit your lock-file. Indicate clearly what PHP-Version you used when creating it. Either by providing the suggested version using the platform-Parameter or by pointing it out in the documentation very clear. And remember to only automatically test the locked dependencies with the PHP-Versions you created the composer.lock
Be careful when you use a lock-file. Check whether there is a hint to the provided version in the composer.json file or in the documentation of the project you are using. Have a look at the CI-config-file, it might give you a hint.
By continuing to use the site, you agree to the use of cookies. That includes scrolling or clicking links. (Sorry for the inconvenience…) more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this. That includes scrolling or clicking links. (Sorry for the inconvenience…)