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

Allow for a build step #178

Merged
merged 2 commits into from
Jul 5, 2015
Merged

Allow for a build step #178

merged 2 commits into from
Jul 5, 2015

Conversation

dchancogne
Copy link
Contributor

Add a ':build' step that can be executed after the deployment has been
done and the code moved to its final destination but before the sysmlink
for the current release has been updated (aka new code is live).
This allows for build steps that require code to be in its final
destination (i.e. some autoloaders resolve full paths, moving the code
after the autoloader has done its setup work breaks the code).

Add a ':build' step that can be executed after the deployment has been
done and the code moved to its final destination but before the sysmlink
for the current release has been updated (aka new code is live).
This allows for build steps that require code to be in its final
destination (i.e. some autoloaders resolve full paths, moving the code
after the autoloader has done its setup work breaks the code).
@gpstathis
Copy link

+1

@rstacruz
Copy link
Member

rstacruz commented Apr 7, 2014

Will this work even if a build step isn't defined?

@dchancogne
Copy link
Contributor Author

Yes @rstacruz, if the build step is not defined, it works just like before.

@fnando
Copy link

fnando commented Apr 16, 2014

+1

@d4be4st
Copy link
Member

d4be4st commented Jan 24, 2015

I am not sure this extra step is really needed. You can always use $release_path in to :launch do block to get use the release path for your autoloaders

to :launch do
  queue "echo #{deploy_to}/$release_path"
end

@dchancogne
Copy link
Contributor Author

@d4be4st The issue is not with getting the value for the actual path.
During the launch block the new version of the app is already running (i.e. the symlink has been updated). Any actual build process (like running CSS thru a preprocessor, concatenating JS ...etc.) would them mean downtime for the application.
These builds steps need to happen before the new version of the app is made live, i.e. in/during the build process. But since the build process is done in a temp directory it causes anything that precompute or cache absolute path to get an invalid path.

Conflicts:
	spec/commands/real_deploy_spec.rb
@dchancogne
Copy link
Contributor Author

@d4be4st Any update on this? Any change you can merge this?

@d4be4st
Copy link
Member

d4be4st commented Jul 5, 2015

Not true. It might be that current path is pointing to the newest path but you still did not restart your application, and that means the old code is still running on your application.

But i will merge this as it seems like a good idea.

d4be4st added a commit that referenced this pull request Jul 5, 2015
@d4be4st d4be4st merged commit 9c76974 into mina-deploy:master Jul 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants