Can psake ignore dependent tasks? - psake

In PSake, is there an option to request that dependent tasks are not not run. For example:
In a build script, Build.ps1:
Task T1 {}
Task T2 -depends T1 {}
Is it possible to do Invoke-psake .\Build.ps1 T2 -ignoredependencies?
The reason for this is that with large projects, testing of tasks that have large number of dependencies (directly or indirectly) takes a long time since all the the dependencies are rebuilt but generally do not need.

Related

bitbake do_image dependency not cached

I have a task do_image_custom that has a dependency on task do_image_ext4.
That task (do_image_ext4) generates an image file containing DATETIME.
The first time I build my image, no errors.
dependency_DATETIME.rootfs.ext4 is generated and used by its dependents.
If I make a change to the consuming task of the ext4 file, because I need to stipulate the dependency on DATETIME.rootfs.ext4.
After I build a second time (without cleaning), I get the error that do_image_custom cannot find newer_datetime.rootfs.ext4
I check the IMGDEPLOYDIR and sure enough, that file doesn't exist and the do_image_ext4 task still has the first timestamp.
My question is, what am I doing wrong here in do_image_custom such that it re-evaluates DATETIME every time it is run without checking with (perhaps) the sstate cache?
The problem was that my custom task (do_image_custom) depended on the output of a prior task. That task output generates an ext4 image with a timestamp in the name.
do_image_custom re-evaluated the DATETIME, even though the dependency (the ext4 file with an earlier DATETIME did not, and therefore was not rebuilt. Hence when do_image_custom executed, it referenced a file that did not exist (the error) because it was not generated (correctly so, because the basehash for the dependency task was unchanged).
The solution was (in front of me all along) to modify my custom task (do_image_custom) to refer to a symlink (also generated in the same step as the ext4) which does not have a DATETIME in the symlink name, hence making do_image_custom invariant to any or no changes to it's dependent step.

Yocto: ROOTFS_POSTPROCESS_COMMAND and do_rootfs

I have a task which has a dependency set as below:
bb.build.addtask('do_function2', 'do_build', 'do_rootfs', d)
There is another task do_function1 that modifies some files in the rootfs:
ROOTFS_POSTPROCESS_COMMAND_append = " do_function1;"
I require do_function2 to be triggered only after rootfs for the image has been populated.
Query is whether the tasks that come under ROOTFS_POSTPROCESS_COMMANDS_append satisfy the do_rootfs dependency that I have set up in the addtask() call?
I want do_function2 to run only after do_function1. Is that the case even if do_function1 is specified under ROOTFS_POSTPROCESS_COMMAND_append?

How do I skip a rake task

Consider the following Rake tasks:
task deploy => [:package] do
end
task package => [:build] do
end
task build do
end
Is there a way to invoke Rake on the command line to execute the package and deploy tasks, but not the build task?
Short answer, no.
The way I usually go about this is instead of using the dependant task notion like you have above:
task deploy => [:package] do
end
I create an alias task for whatever action that is to be completed:
task all => [:build, :package, :deploy]
task fastDeploy => [:package, :deploy]
task deploy do
end
task package do
end
task build do
end
It's not very elegant, but I do find it to be more readable and you can visibly see the dependency of tasks on other tasks instead of the kind of spaghetti code structure the dependant notion can result in... when you have a lot of task it can be awkward to debug the logic to figure what's gone wrong and where at times.
Hope this helps.

Inherit roles from parent tasks in Capistrano callbacks

I have several tasks which all must check that the machines serving as roles have a certain file with certain contents. The logic is reasonable to separate into a prerequisite, or a callback.
task t1, :roles => [:r1] do
...
end
task t2, :roles => [:r2,:r3] do
...
end
before <what?> do
# must only run on :r1 when triggered by t1,
# and only on :r2 and :r3 when triggered by t2!
<ensure role given to parent task has a given file>
end
How do we do that in Capistrano?
It turns out that a before callback can invoke a regular def, in which case it runs for the roles of the parent task. If, however, you call a task there, and that task has no roles, all roles will be used to run it. The real question is where are the dependencies across tasks...

Which tool / technology: System management for databases and dependent services

A follow-up on this system management question:
Since I probably will not get much feedback on serverfault I'll give it a try here.
My main concern is to reflect the dependencies between the databases, services ans tasks/jobs I'll have to manage.
Besides considering Powershell, I even thought about using MSBuild because it would allow for modeling dependencies and reuse configuration targets.
In other words: What technology should I use to develop a flexible solution that will allow me to stop service A, B and C on machine D in the right order and disable task E on machine F when taking down database X?
... and I'd like to reuse the part for stopping service B and C when taking down database Y.
If you are familiar with PowerShell and want to work with dependencies, try psake. What it looks like:
psake script.ps1:-------
properties {
$dbServer = 'sqlexpress'
...
}
task default -depend StopServer1, StopServer2
task StopS1 -depend MakeS1Backup, StopSqlServer1 {
...
}
task MakeS1Backup {
... make backup
}
task StopSqlServer1 {
stop-service ...
}
# and anything similar to StopServer2
Then you may call it like this (there are more options):
Invoke-Psake script.ps1
#or
Invoke-Psake script.ps1 -task StopS1 #calls only StopS1 task and all other scripts it depends on
#or
Invoke-Psake script.ps1 -task MakeS1Backup #only backups S1, it doesn't depend on anything else
What it does - it stops server 1 (task StopS1) and before that it processes all the tasks that StopS1 depends on. So before stopping S1 backup of S1 is made and Sql server 1 is stopped and so on.
I like it much better than msbuild configuration, which is very verbose and ugly (although very powerfull).