Skip to content
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

Show custom arguments in web ui and forward them to worker #1841

Merged
merged 6 commits into from
Aug 9, 2021

Conversation

cyberw
Copy link
Collaborator

@cyberw cyberw commented Aug 5, 2021

This is WIP. I'm not sure showing all custom arguments in the UI is the best solution (and it would also be nice to be able to show some of the default ones). What do you think @TWoeste

I tried to make that "advanced" tab thingy but it turned out to be too much work :)

@TWoeste
Copy link

TWoeste commented Aug 6, 2021

I do think this is a cleaner approach to adding custom start UI. I do think that the whole point to add these arguments would be to access them somehow in your tasks to change how they act (so on the worker runner for distributed tests). For instance if you wanted to specify the username and password of the requests it would be best if you could access these in the worker to set them in the header of the requests. Another downside to this approach is all of your custom fields will be text boxes so its hard to predict what users will put there. In the end I think its a good approach to solve my issue. In my local branch I solved the problem with not being able to access the variables in the worker branch by sending a message from the master runner to the worker runner as suggested here. @cyberw

@TWoeste
Copy link

TWoeste commented Aug 6, 2021

Would the parsed_options be populated with the correct data on the worker instance of env?

@cyberw
Copy link
Collaborator Author

cyberw commented Aug 6, 2021

I do think that the whole point to add these arguments would be to access them somehow in your tasks to change how they act (so on the worker runner for distributed tests). For instance if you wanted to specify the username and password of the requests it would be best if you could access these in the worker to set them in the header of the requests.

This approach makes them accessible in tasks by self.environment.parsed_options.my_argument

Would the parsed_options be populated with the correct data on the worker instance of env?

Not automatically no, that would also have to be addressed (hence the draft status :)

@TWoeste
Copy link

TWoeste commented Aug 6, 2021

This all looks amazing to me :). I think it will become one of the more uses locust feature when implements. Thanks!

@cyberw
Copy link
Collaborator Author

cyberw commented Aug 7, 2021

@TWoeste Can you try this out before I merge it?

@cyberw cyberw marked this pull request as ready for review August 7, 2021 20:25
@cyberw cyberw changed the title Show custom arguments in web ui. Fixes #1822 (maybe?) Show custom arguments in web ui and forward them to worker. Fixes #1822 Aug 7, 2021
@cyberw cyberw changed the title Show custom arguments in web ui and forward them to worker. Fixes #1822 Show custom arguments in web ui and forward them to worker Aug 7, 2021
…ments to workers, but only the custom arguments (not built-in ones) are actually processed by the worker. In the future we could (should?) make it so that all parameters will be accepted.
@cyberw cyberw force-pushed the show-custom-arguments-in-web-ui branch from 93d5a13 to e3d969d Compare August 7, 2021 21:00
… workers. Update the add_command_line_argument.py to actually USE the custom argument.
Copy link

@TWoeste TWoeste left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Tested it with the example file!

@cyberw cyberw merged commit 88324f5 into master Aug 9, 2021
@cyberw cyberw deleted the show-custom-arguments-in-web-ui branch August 9, 2021 14:06
cyberw added a commit to SvenskaSpel/locust-plugins that referenced this pull request Aug 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants