-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add a 'Deploy to Heroku' button #1285
base: master
Are you sure you want to change the base?
Conversation
This allows someone that forks this repository to download the bundled package from his build as an artifact for easy inspection.
GitHub CI has both installed, but not every system does so - Heroku
Heroku uses 'buildpacks' which contain tools needed to build an application for a given technology, but allow little customization and have a pre-set number of tools included (or I haven't found a way to include both `composer` and `node` in 1 environment, short of defining such a build environment by hand). This is why we need to invoke 2 seperate buildpacks sequentially: 1. `composer install`` 2. `npm run build` Defining the environment variables like this allows the developer to easily fill in the required values with minimal overhead. Heroku heavily uses environment variables to configure applications, and doesn't allow for after-deployment adjustments. Using environment variables for configuration does not fit into the current way the config is set up since this uses constants, which need to be fixed at the start of the program. This leads us to the following 2 points: 1. Since these are constants, they cannot be read directly from the environment and we have to perform an in-file replace to make them active. 2. A change in environment variables triggers a restart of a dyno, but not a redeploy. This means that we cannot configure these at build, so we have to perform this change when a Dyno is (re)started. The [.profile](https://devcenter.heroku.com/articles/dynos#the-profile-file) file allows us to manipulate the environment and files for the Dyno, or runner, allowing us to alter the `config.php` file and apply the desired config, while still sticking to non-mutable configuration once the application is booted.. We also need a custom logger to propagate the CodeIgniter logs towards Heroku. See https://devcenter.heroku.com/articles/php-logging#codeigniter-3-x
@alextselegidis: |
Hello! Thanks for this PR! Let me check this out and get back to you.
|
@alextselegidis just a ping so this is not forgotten. Hope you're having a good time 👋🏼 |
Thanks!
|
Not sure if this one is forgotten or not, but closing it due to inactivity. |
Hi @daneov, I'd still want to take a look on this one. Let me keep this alive :)
|
That was accidental, please ignore. |
Any word on this change? |
Hello! I'll write back on this one soon.
|
Goal of this PR
To facilitate easy deployment to Heroku, and perform the changes needed to make that possible.
This PR resolves #1284.
Individual commits
composer test
running, and don't know why there were so many deletions in thepackage.json
file, but everything still works.composer
andnode
in 1 environment is not possible in Heroku, since they providebuildpacks
, specialised environment for building eithernode
orphp
environments.I've used the environment variable
CI
to distinguish between Heroku and another environment, since they commonly set that to indicate a CI environment. Not making this distinction would result in a failing build at Heroku because the binarycomposer
would not be present in anode
environment.