What is the equivalent API of Capistrano::CLI#password_prompt in Capistrano 3? It seems to me this DSL has been removed. For the time being, I ended up using highline gem.
It was removed as Cap is an automation tool, for special use cases like your own Highline is Perfect. Cap3 does include an "#ask" method (see the docs) which is probably suitable for password input, but is used by default for asking which branch do deploy.
Related
I would like to validate my CloudFormation templates before running them. I know about the aws cloudformation validate-template ... cli command, but that ignores incorrect property names. I don't know what the point of that cli command is if it won't catch these kind of mistakes.
I want something that will catch those kind of mistakes before running the templates. An IDE or external service that does this would be fine.
We had a quite similar issue with erroneous Cloud-Formation templates and created (I’m a co-author) a command-line tool, that validates them - besides the standard AWS validation it also has many custom checks, that were essential for us:
https://github.com/Appliscale/perun
I believe it doesn't support property names validation yet, but any feature requests (or pull request even better), are welcome. We will do our best to address them as soon as we can.
After installing Perun, to validate the template you can use the command validate:
~ $ perun validate <PATH TO THE TEMPLATE>
Moreover, it also allows managing (creation, updates etc.) CF stacks and monitoring the status updates.
The cfn-lint tool was built for this exact purpose. It is actively maintained by the AWS team and it has a couple of IDE integrations.
Same issue with me. There is no way to validate the property name. But you can reduce the mistake using Atom IDE with plugins cloudformation, it helps me to create a resources property so I can reduce my typo mistakes.
I'm currently in the middle of upgrading our API from v0.12 of Sails to v1. Not the easiest task, but will be worth it.
The current problem I'm having, is converting our old "ModelName.query" calls to the new style, which is supposedly "sails.getDatastore". Great, fine.
Except, that when trying to do this in config/bootstrap.js, I constantly get the error "sails.getDatastore is not a function".
Yes, I am using the default sails-hook-orm, the .sailsrc has it turned on explicitly; and yes, I have globals turned on.
Is the problem that the function isn't registered until after bootstrap? Because that is not an option for us; bootstrap is validating our database schema before lift (custom code, using native queries), so our production servers fail to deploy if we missed a database update. It eliminates a ton of human error.
Thanks for taking the 1.0 plunge!
I'm not sure what you mean by the "default" sails-hook-orm -- that hook is installed directly as a dependency on each Sails 1.0 project -- but I can almost guarantee that the version you're using is not correct. I would do:
npm cache clean
npm install sails-hook-orm#beta
in your project to make sure you get the latest (currently v2.0.0-21). It adds getDatastore to the app object when it initializes.
I've been using mViever for several months and it fitted me perfectly, however it doesn't support proper authentification (when mongod is launched with --auth parameter). So, now I'm trying to find any good replacement for MacOS with auth support.
Tried MongoHub, but it doesn't support most of common Mac hotkeys (even Enter doesn't work as submit), and by the way, it also has some bugs with authentification. To be shorter, which of these http://www.mongodb.org/display/DOCS/Admin+UIs to choose? I've tested some of them, but nothing really liked (except old good mViever).
I assume that's a typo and you are referring to mViewer. As you can see here, it does support authentication:
http://imaginea.github.com/mViewer/0.9/pages/getting_started.html
There were issues with auth in 0.9.1, but they have been fixed. See here:
https://github.com/Imaginea/mViewer/issues/75
For some reason, the 0.9.2 binaries are not available yet (even though the comment says October), but it's not too hard to build yourself:
git clone https://github.com/Imaginea/mViewer.git
cd mViewer
mvn clean package -Prelease -DskipTests
Once all that was finished, I took a look in the target folder:
cd target
ls mViewer-0.9.2.*
Here's my mViewer 0.9.2 session logged in with user "adam" to an auth enabled mongod:
I just released a minimalist mongodb data viewer for nodejs github.com/marcdelalonde/mongo-viewer
I have planned to add auth support very soon :)
On my website, in the footer, i want to clearly show which version of the code is live.
I am using git as version control. It would be great to get some visual feedback to know which version is actually live.
I want to show some readable number, like a gem version number. I could create a VERSION file, which i manage and increase every time it is needed.
I am curious if there are any existing solutions already out there? It would be preferable if it could e.g. use tag information from git.
I found a gem that actually does exactly what i need: version.
It allows to manage the version dead-easy, with the needed rake-tasks without the coupling to jeweler, and also allows to tag github in the process.
When developing a gem, i keep using jeweler, but for my rails-projects this is just what i need.
For more info see the gem's documentation.
Jeweler has some rake tasks that handle versioning pretty well for you. I have only used it for gems, but you can probably drop in a VERSION file and use the same rake tasks in a rails app. I have actually been thinking about doing the same thing for my app.. I will update this answer with more details if I get to it soon. For my gems I added a few new rake tasks that combine some of the jeweler tasks. Every time I have a new version I run one of the tasks and it increments the version (major,minor or patch), pushes my code to github and tags it all in one operation:
namespace :version do
desc "create a new version, create tag and push to github"
task :github_and_tag do
Rake::Task['github:release'].invoke
Rake::Task['git:release'].invoke
end
desc "bump patch push to github"
task :patch_release do
Rake::Task['version:bump:patch'].invoke
Rake::Task['version:github_and_tag'].invoke
end
desc "bump minor push to github"
task :minor_release do
Rake::Task['version:bump:minor'].invoke
Rake::Task['version:github_and_tag'].invoke
end
desc "bump major push to github"
task :major_release do
Rake::Task['version:bump:major'].invoke
Rake::Task['version:github_and_tag'].invoke
end
end
get jeweler if you dont have it and create a fake gem, put it on github and play around with the tasks until you get a feel for them. I took me a few tries (and peeks at the source) to fully understand what it was doing.
If you run these tasks every time you have a new version, your VERSION file will be in sync with your github project. If it was me, I would just read in the version number from the file and use something like settingslogic to set up a constant.. or you can set it up in an initializer. That way, you know that every time you restart your app, it will read the correct version
I'm trying to customize the location of the user.config file. Currently it's stored with a hash and version number
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
I want to it be agnostic to the version of the application
%AppData%\[CompanyName]\[ProductName]\
Can this be done and how? What are the implications? Will the user lose their settings from the previous version after upgrading?
I wanted to add this quoted text as a reference for when i have this problem in the future. Supposedly you can instruct the ApplicationSettings infrastructure to copy settings from a previous version by calling Upgrade:
Properties.Settings.Value.Upgrade();
From Client Settings FAQ blog post: (archive)
Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?
A: There are couple of reasons why the
user.config path is version sensitive.
(1) To support side-by-side deployment
of different versions of an
application (you can do this with
Clickonce, for example). It is
possible for different version of the
application to have different settings
saved out.
(2) When you upgrade an
application, the settings class may
have been altered and may not be
compatible with what's saved out,
which can lead to problems.
However, we have made it easy to
upgrade settings from a previous
version of the application to the
latest. Simply call
ApplicationSettingsBase.Upgrade() and
it will retrieve settings from the
previous version that match the
current version of the class and store
them out in the current version's
user.config file. You also have the
option of overriding this behavior
either in your settings class or in
your provider implementation.
Q: Okay, but how do I know when to
call Upgrade?
A: Good question. In Clickonce, when
you install a new version of your
application, ApplicationSettingsBase
will detect it and automatically
upgrade settings for you at the point
settings are loaded. In non-Clickonce
cases, there is no automatic upgrade -
you have to call Upgrade yourself.
Here is one idea for determining when
to call Upgrade:
Have a boolean setting called
CallUpgrade and give it a default
value of true. When your app starts
up, you can do something like:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
This will ensure that Upgrade() is
called only the first time the
application runs after a new version
is deployed.
i don't believe for a second that it could actually work - there's no way Microsoft would provide this ability, but the method is there just the same.
To answer the first question, you technically can put the file wherever you want, however you will have to code it yourself, as the default place the file goes to is the first of your two examples. (link to how to do it yourself)
As for the second question, it depends on how you deploy the application. If you deploy via a .msi, then there are two hashes in the properties of the setup project (that the msi is built from), the 'upgrade code' and the 'product code'. These determine how the msi can be installed, and if it upgrades, overwrites, or installs beside any other version of the same application.
For instance, if you have two versions of your software and they have different 'upgrade' codes, then to windows they are completely different pieces of software regardless of what the name is. However if the 'upgrade' code is the same, but the 'product' code is different then when you try to install the 2nd msi it will ask you if you want to upgrade, at which time it is supposed to copy the values from the old config to a new config. If both values are the same, and the version number didn't change then the new config will be in the same location as the old config, and it won't have to do anything. MSDN Documentation
ClickOnce is a little bit different, because its based more off of the ClickOnce version # and URL path, however I have found that as long as you continue to 'Publish' to the same location the new version of the application will continue to use the existing config. (link to how ClickOnce handles updates)
I also know there is a way to manually merge configs during the install of the msi using custom install scripts, but I don't remember the exact steps to do it... (see this link for how to do it with a web.config)
The user.config file is stored at
C:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<version>
<C:\Documents and Settings> is the user data directory, either non-roaming (Local Settings above) or roaming.
<username> is the user name.
<companyname> is the CompanyNameAttribute value, if available. Otherwise, ignore this element.
<appdomainname> is the AppDomain.CurrentDomain.FriendlyName. This usually defaults to the .exe name.
<eid> is the URL, StrongName, or Path, based on the evidence available to hash.
<hash> is a SHA1 hash of evidence gathered from the CurrentDomain, in the following order of preference:
1. StrongName
2. URL:
If neither of these is available, use the .exe path.
<version> is the AssemblyInfo's AssemblyVersionAttribute setting.
Full description is here http://msdn.microsoft.com/en-us/library/ms379611.aspx
(I'd add this as a comment to #Amr's answer, but I don't have enough rep to do that yet.)
The info in the MSDN article is very clear and appears to still apply. However it fails to mention that the SHA1 hash is written out base 32 encoded, rather than the more typical base 16.
I believe the algorithm being used is implemented in ToBase32StringSuitableForDirName, which can be found here in the Microsoft Reference Source.