Why is Capistrano using /u/apps/ in the current_path, even though I've set :deploy_to - capistrano

For some reason Capistrano is failing on just about every operation, because it seems to think my current_path should be in /u/apps/. I've set all the variables that (AFAIK) should be set, and eliminated all other similar default paths, but this one persists.
Here are the values returned by relevant variables:
current_dir: current
releases_path: /var/www/vhosts/dev.www.example.com/html/releases
shared_path: /var/www/vhosts/dev.www.example.com/html/shared
current_path: /u/apps/www.example.com/current
I'm setting :deploy_to, so shouldn't current_path be computed based on that!?
set :deploy_to, "/var/www/vhosts/dev.www.example.com/"

The kind of kludgey solution is just to manually
set :current_path, ""
The better solution, which can be found explained in this e-mail thread by Jamis Buck himself, is to use lazy evaluation when you set another variable that depends on current_path. In my case, I had a setting something like this
set :some_path_var, "#{current_path}/some/path/"
that I had to change to something like this:
set(:some_path_var) { "#{current_path}/some/path/" }
By passing in a block, the :some_path_var was not immediately evaluated, and did not force current_path to be evaluated based on a default value for :deploy_to

So I had this issue as well and I found that this was the best solution.
Add this to your config/deploy.rb
desc "Make sure the symlink will be from the right directory"
task :change_correct_dir, roles: :web do
set :current_path, File.join(deploy_to, current_dir)
end
before "deploy:create_symlink", "deploy:change_correct_dir"
I got the idea from looking at the source of the capistrano gem and finding
_cset(:current_path) { File.join(deploy_to, current_dir)
in
lib/capistrano/recipes/deploy.rb

This can also happen if you don't specify a task in your cap command.
cap deploy:setup
Will attempt to set up Capistrano in /u/apps
cap production deploy:setup
Will set up Capistrano in the directory specified in :deploy_to.

Related

Dataflow: set DataflowPipelineDebugOptions

My pipeline gives OOM errors constantly so I read a fowllowing answer and try to set --dumpHeapOnOOM and --saveHeapDumpsToGcsPath. But it seems that these options do not work. Do I need to change my code or modify something else?
Memory profiling on Google Cloud Dataflow
You will want to check configuring-pipeline-options.
The current way in Apache Beam (2.9.0) to configure pipeline option in command line is --<option>=<value>.
In your case, you can set --dumpHeapOnOOM=true --saveHeapDumpsToGcsPath="gs://foo"

How to reset VSTS counter?

We have a need to reset VSTS counter. I do not see any way to do this through UI. There is a way to do it by directly invoking reset build counter REST API, but in order to do this, you need to know the counter id, which you should be able to find out by invoking get a definition REST API. Unfortunately, no matter what I do get a definition call does not return build definition counter.
What am I missing?
Scott Dallamura from Microsoft wrote this thread:
the counters feature was experimental and removed back in March of
this year. I'm not sure how it even got into the documentation, but
I'll make sure it gets cleaned up.
I also didn't success to get the counterId in an API call.
At workaround, you can reset the revision of the build number if you change the build definition name, you can just add/remove a character.
Instead of trying to reset the counter variable, you could create a new variable with a GUID prefix.
This solution creates duplicate counters which might not be ideal but this gives you the ability to revert back to the previous counter values, if necessary.
Please see the following YAML code snippet
variables:
...
#Change this Guid if you require a reset seed on the same value.
resetCounterGuid: 'efa9f3f5-57fb-4254-8a7a-06d5bb365173'
buildrevision: $[counter(format('{0}\\{1}',variables['resetCounterGuid'],variables['YOUR_DEFINED_VARIABLE']),0)]
...

Re-add value into EXTRA_OECONF_<name> after it was removed by EXTRA_OECONF_remove_<name>

To configure a component I need to add --enable-feature into EXTRA_OECONF_somename
So I tried to do:
EXTRA_OECONF_append_somename = --enable-feature
But it did not help. After investigation it was found that the one of the third-party recipe contains the following line:
EXTRA_OECONF_remove_somename = --enable-feature
I can't modify the third-party recipe.
Is there a way to add --enable-feature into EXTRA_OECONF_somename
Thank you.
I'm afraid not. The _remove operations are always applied last so there is no way to undo them. I would say that the original recipe shouldn't be using it - _remove is intended for distro policy where you want to say "I don't care how this item got in the value, just remove it".
For preference the original recipe should instead it should be using PACKAGECONFIG to control addition (or not) of this feature.

Cleanup for running spec files in series in Protractor

I am running multiple specs using a Protractor configuration file as follows:
...
specs: [abc.js , xyz.js]
...
After abc.js is finished I want to reset my App to an initial state from where the next spec xyz.js can kick off.
Is there a well defined way of doing so in Protractor? I'm using Jasmine as a test framework.
You can use something like this:
specs: ['*.js']
But I recommend you to separate the specs with a suffix, such as abc-spec.js and xyz-spec.js. Thus your specs will be like this:
specs: ['*-spec.js']
This is done to avoiding the config file to be 'run'/tested if you put the config file in the same folder as your tests/spec files.
Also there is downside that the test will be run in 0 -> 9 and A -> Z order. E.g. abc-spec.js will run first then xyz-spec.js. If you want to define your custom execution order, you may prefix your spec files' names, for instance: 00-xyz-spec.js and 01-abc-spec.js.
To restart the app, sadly there is no common way (source) but you need to work around to achieve it. Use something like
browser.get('http://localhost:3030/');
browser.waitForAngular();
whenever you need to reload your app. It will force the page to be reloaded. But if your app uses cookie, you will also need to clean it out in order to make it completely reset.
I used a different approach and it worked for me. Inside my first spec I am adding Logout testcase which logouts from the app and on reaching the log in page, just clear the cookie before login again using following:
browser.driver.manage().deleteAllCookies();
The flag named restartBrowserBetweenTests can also be specified in a configuration file. However, this comes with a valid warning from the Protractor team:
// If [set to] true, protractor will restart the browser between each test.
// CAUTION: This will cause your tests to slow down drastically.
If the speed penalty is of no concern, this could help.
If the above doesn't help and you absolutely want to be sure that the state of the app (and browser!) is clean between specs, you need to roll out your own shellscript which gathers all your *_spec.js files and calls protractor --specs [currentSpec from a spec list/test suite].

Change attributes of change-set from command line

I tried using aegis -change_attributes to change the brief_description of my current change set but it didn't work.
aegis -change_attributes description="test"
What should I do to make this work?
EDIT: The command I was looking for was
aegis -change_attributes brief_description="$DESC";
Since no answer was given (for quite some time) I'm adding the solution I gave in the comments, as the anser:
The above command is correct if you want to set the extensive description. If one wants to just set the brief description "aegis -change_attributes brief_description="$DESC"" has to be used