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

access world parameters from setParallelCanAssign function #2065

Open
seddik-st opened this issue Jun 23, 2022 · 5 comments
Open

access world parameters from setParallelCanAssign function #2065

seddik-st opened this issue Jun 23, 2022 · 5 comments
Labels
⚡ enhancement Request for new functionality

Comments

@seddik-st
Copy link

Hello,

is there a way to pass those tags as world class parameters ?

const myTagRule = atMostOnePicklePerTag(["@tag1", "@tag2"]);

@aurelien-reeves
Copy link
Contributor

Hi @seddik-st :)

I am not sure to understand your question

What would you like to do exactly? Would you have a more comprehensive example?

And without that in mind, what are you trying to achieve exactly? What is the issue you are facing that you try to workaround with your idea?

@seddik-st
Copy link
Author

Hi @aurelien-reeves,

Thank you for your quick reply.

We are trying to setup a CI profile that run many workers in parallel however we need to add a custom assign that prevent some sets of scenarios from running in parallel as showed in this tutorial.

It would be more elegant if we could pass those tags as world parameters in our CI profile (defined in the cucumber config file).

I hope it's clearer now :)

@aurelien-reeves
Copy link
Contributor

I am not sure it is possible to pass those tags as world parameters. @davidjgoss do you confirm?

Regarding what you are trying to do, I am still puzzled:

  • the solution you found in the tutorial does not fit your needs?
  • why do you think it would be more elegant as world parameters?
  • if you use the cucumber config file, why don't you use simple tag expressions to select the scenarios you want to execute or not?

@davidjgoss
Copy link
Contributor

davidjgoss commented Jun 23, 2022

So my understanding here is that we're talking about custom work assignment and specifically wanting to use the atMostOnePicklePerTag helper but without having the specific tags live in the support code, and be able to pass them through some config mechanism instead. This is unrelated to using tags to control which scenarios are executed, I think.

One thing we could do is add a third argument to the setParallelCanAssign consumer interface and give it the resolved configuration object - you could then pull world parameters from there.

Honestly though that feels a bit overwrought and for this case I would probably just advise to set an environment variable in your CI and then pick that up from your support code, like:

const myTagRule = atMostOnePicklePerTag(process.env.PARALLEL_ASSIGNMENT_TAGS.split(',');

@seddik-st
Copy link
Author

Hi @davidjgoss,

Thank you for your answer.
We are aware of the alternative solution you already mentioned. However, we would like to have all cucumber config in one place and we thought that world parameters is the best place.

I agree with @aurelien-reeves to some degree, we can assign a special tag to each scenario that we want to prevent it from running in parallel (let's say @RunInSequence) However like this, we will have a lot of scenarios running under one worker which will slow down the execution time significantly. I'm not sure of the expected behavior please correct me if i'm wrong.

@davidjgoss davidjgoss added the ⚡ enhancement Request for new functionality label Aug 15, 2022
@davidjgoss davidjgoss changed the title Tag rule as world parameters access configuration from setParallelCanAssign function Aug 15, 2022
@davidjgoss davidjgoss changed the title access configuration from setParallelCanAssign function access world parameters from setParallelCanAssign function Aug 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⚡ enhancement Request for new functionality
Projects
None yet
Development

No branches or pull requests

3 participants