Skip to content
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.

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

NEW Add ability for the upgrader to self-update #153

Merged

Conversation

@maxime-rainville
Copy link
Contributor

maxime-rainville commented Jan 30, 2019

This adds the ability for the upgrader to self-update. Key changes include:

  • Ability to define the version number on build in a .env file that gets embedded in the PHAR executable
  • Add a new self-update commands.
    • This only works for PHAR executables. You get warnings if you try to call it on the composer install.
    • Also supports rollbacks.
  • Switch to building the PHAR on PHP7.1. The idea being that it's less likely we'll install a library that relies on PHP7.2 features.
  • Update deploy logic to keep an archive of older release and to compute md5 hashes.
  • Added a one time warning if you are using an outdated version. This save a file in a tmp folder. So you don't keep getting the message over and over.

Additional notes

I explored the possibility to sign our phar executable, but that would require us to publish a public key and then have the key installed along with the PHAR executable. To get this working we would need to produce an installation script like the one composer provide.

There's not any updated unit test. This is because a lot of the logic is dependent on the file being executed through a PHAR and on calling some web base service to get the latest release. So there's not really nice elegant way of unit testing this.

Testing the updated build script

There's a condition on the .travis.yml file so the deploy logic only kick in if you are doing a release on the silverstripe/silverstripe-upgrader repo. You'll need to comment this bit out to test the build logic on a personal repo or on open-sausages.

Parent issue

@maxime-rainville maxime-rainville mentioned this pull request Jan 31, 2019
3 of 4 tasks complete
.env-sample Outdated Show resolved Hide resolved
.travis.yml Show resolved Hide resolved
.travis.yml Outdated Show resolved Hide resolved
bin/upgrade-code Show resolved Hide resolved
doc/en/releasing.md Outdated Show resolved Hide resolved
src/Console/SelfUpdateCommand.php Show resolved Hide resolved
src/Console/SelfUpdateCommand.php Show resolved Hide resolved
src/Console/SelfUpdateCommand.php Show resolved Hide resolved
src/Util/UpdateChecker.php Outdated Show resolved Hide resolved
src/Console/SelfUpdateCommand.php Outdated Show resolved Hide resolved
@maxime-rainville

This comment has been minimized.

Copy link
Contributor Author

maxime-rainville commented Feb 10, 2019

@dre I think I've addressed all your points. Maybe try to get the phar build working on the open sausages repo just to make sure it works as expected. You'll need to hack.travis.yml a bit. You can do dummy releases there.

@maxime-rainville maxime-rainville force-pushed the open-sausages:pulls/autobuild-version-numer branch from 167b82e to cd10158 Feb 14, 2019
@maxime-rainville maxime-rainville dismissed bergice’s stale review Feb 14, 2019

All feedback has been addressed.

@maxime-rainville

This comment has been minimized.

Copy link
Contributor Author

maxime-rainville commented Feb 14, 2019

Confirmed the autobuild works and generates a phar that can self-update. @bergice is on holiday, so I'll merged as-is.

@maxime-rainville maxime-rainville merged commit 6e438ca into silverstripe:master Feb 14, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@maxime-rainville maxime-rainville deleted the open-sausages:pulls/autobuild-version-numer branch Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.