Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

reading the variable "latest_release" before "deploy" task happens makes capistrano BREAK #440

Closed
knocte opened this Issue Apr 16, 2013 · 21 comments

Comments

Projects
None yet
3 participants

knocte commented Apr 16, 2013

If you set up some task this way:

before 'deploy', 'some_task',

And in some_task you simply read the "latest_release" variable (in a puts line for instance), then:

Current results:
a) If it's the first deploy ever in capistrano (the www folder doesn't exist), capistrano breaks completely, it cannot deploy.
b) If it's not the first deploy, then it will make capistrano change its behaviour with regards to the "current" symlink, because it will point to the previous release instead of the last one (after the deploy happened).

Expected results:
a) It should work.
b) It should point current to the latest release.

This is a big fuckup IMHO.

Owner

leehambley commented Apr 16, 2013

This is a big fuckup IMHO.

Profanity aside, you may have a point. I'll take a patch.

@leehambley leehambley closed this Apr 16, 2013

knocte commented Apr 16, 2013

Why do you close the issue?

Owner

leehambley commented Apr 16, 2013

Because you don't offer a patch, and profanity really pisses me off.

knocte commented Apr 16, 2013

Mutable programming pisses me off even more.

Anyway, the point of github issues is to have a bug tracker.

The contributions comes in the pull-requests tab.

Owner

leehambley commented Apr 16, 2013

Indeed, in short - if there's no release, you are doing something wrong if you are calling latest_release. It's not safe for use when it's a cold deploy. It's that simple.

There are other variables which are safe for use throughout the deploy process.

Capistrano, the 2.0.x branch mainline is effectively on the verge of being deprecated, send a patch or things won't be fixed. And even if you do send a patch, changing the behaviour of core variable lookups is not something I approach lightly.

I'd rather invest that time into the v3 branch which will coincide with the Rails 4 release in the coming weeks, and have a stable version which has fewer insane design decisions behind it.

Owner

leehambley commented Apr 16, 2013

As for your second point, you may be onto something there, but it's too late to change it, it's unreasonable overhead to call back to the server to calculate that every time, the results are cached for a reason. If you populate the cache with bad data, then you can't really effectively clear it. I accept that it's confusing, but I won't change it.

knocte commented Apr 16, 2013

I understand that latest_release may not have the proper value when it's queried at the wrong time... but CHANGING BEHAVIOUR???? Sorry for the caps, but really finding out this bug has put me on my nerves.

In regards to your backwards-compatibility policy: fair enough, I understand if you prefer to accept only a patch to fix this in master rather than the 2.0.x branch, but:

a) I never proposed to fix it in a branch.
b) This bug is not fixed yet on any branch, so it should be reopened. Otherwise people confused about it will not be able to find it.

This is, my friend, how bug trackers work.

Owner

leehambley commented Apr 16, 2013

I won't fix it, and it's been the way it is for five years without anyone running into problems. I can't afford the time to test it, fix it and make sure it's safe before releasing it. That's what it boils down to. Those variables are a source of a lot of confusion, and they are fragile, and have different meanings wherever you call them, anyway.

I'd like to be able to fix it, your profane issue report aside; but the reality is, I simply can't.

knocte commented Apr 16, 2013

Then leave this issue open until the end of times.

knocte commented Apr 16, 2013

Otherwise it would be the first time in my entire life in which I see a bug closed as WONTFIX.

I mean, I've seen feature requests closed as WONTFIX status. But bugs? It's like denying to recognize that there is a bug.

knocte commented Apr 16, 2013

Just for the sake of people being able to find the issue (and be enlightened by the work-around: "not read a variable"), this issue should remain open.

@leehambley leehambley reopened this Apr 16, 2013

Owner

leehambley commented Apr 16, 2013

Agreed. I've re-ragged with v2.

@leehambley leehambley closed this Oct 7, 2013

knocte commented Nov 2, 2013

Why did you close this? People are getting here from this SO question: http://stackoverflow.com/questions/3141454/deploysymlink-on-capistrano-points-the-current-directory-to-previous-release/16043844#16043844 and if they find this issue closed, they might be misled into thinking that it is fixed.

Owner

kirs commented Nov 2, 2013

@knocte did you reproduce it on v3?

knocte commented Nov 2, 2013

Oh, when was that released?

Owner

leehambley commented Nov 2, 2013

See rubygems, early september
On 2 Nov 2013 20:30, "Andres G. Aragoneses" notifications@github.com
wrote:

Oh, when was that released?


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/440#issuecomment-27630493
.

knocte commented Nov 2, 2013

Ok, then I have not tested that. And I'm afraid I will not be able to test it very soon.

Just one advice: if you want to close issue in order to request feedback from users about new versions, add a comment explaining why you are closing the issue.
Thanks

Owner

leehambley commented Nov 3, 2013

We have more than 100 obsolete issues to close, and past experience
suggests the OPs never reapond
On 2 Nov 2013 20:36, "Andres G. Aragoneses" notifications@github.com
wrote:

Ok, then I have not tested that. And I'm afraid I will not be able to test
it very soon.

Just one advice: if you want to close issue in order to request feedback
from users about new versions, add a comment explaining why you are closing
the issue.
Thanks


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/440#issuecomment-27630609
.

knocte commented Nov 5, 2013

That doesn't respect the Robust principle ;) http://en.wikipedia.org/wiki/Robustness_principle

knocte commented Mar 14, 2017

People are still upvoting my stackoverflow answer linked above, which seems to hint that this bug is still present in 3.x.

Owner

leehambley commented Mar 14, 2017

thanks for checking the so answer upvote rates @knocte

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment