-
Notifications
You must be signed in to change notification settings - Fork 223
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
'task' and 'connection' objects are poorly documented #933
Comments
Rex::Task is documented here: http://rexify.org/docs/api/1.3/rex/task.pm.html (updated on 528017a for You can take a look at the implementation of connection-releated stuff under Rex::Interface::Connection namespace, but you're right, they are not yet documented. Can you maybe help with adding the bits you missed? ps.: I'm not sure if the reporting output details when using |
Ah, indeed Rex::Task is the document I was thinking of. task->user is still empty for me, I'll try to create a test case. |
Turns out that task->user is set unless feature "0.31" or newer is enabled. Why is that? |
@shattered user "foo";
password "bar";
task "mytask", sub {}; # connect with user: foo
user "otheruser";
password "otherpass";
task "othertask", sub {}; # connect with user: otheruser This was removed in favour of the So since since 0.31 the task has a new attribute |
Yeah, but why it's reported as empty? :) |
Thanks for you patience, @shattered! TL;DR:This issue seems to be a mixture of several smaller questions together, which makes it harder than necessary to process and track properly. Given the combination of
I am closing this issue now, with more detailed notes below. Any readers of this who still have questions or concerns, please reach out on one of our support channels. Longer versionNevertheless, let me summarize some notes below.
Right, Rex::Interface::Connection classes still could use some documentation. I would rather deal with that separately, and will open another issue about that single aspect.
Docs are available in Rex::Task.
It's certainly hard to guess a correct answer for a question from years ago without a code example to reproduce the exact same use case that might have been confusing back then. There were two notable code changes which might have addressed your concern since then:
I'm testing with today's latest version with the following code: use Rex;
use Rex::TaskList;
task 'test', sub {
say 1;
};
use DDP;
my $task = Rex::TaskList->create->get_task('test');
p $task->user(); and it returns the expected value (my local username autodetected as a fallback).
There was no example code attached to help reproduce the same use case, but at first glance it feels possibly "by design" to me. While executing |
(Actually clicking the close button now 🤣 ) |
'connection' is at least mentioned in the API doc (http://rexify.org/docs/api/1.3/rex/commands.pm.html#connection) but 'task' is not.
Plus, it appears that task->user is never set, and task->name is not updated when the task has been launched via needs() -- in this case it still reports dependee's name.
The text was updated successfully, but these errors were encountered: