Customized explicit job requirements are doubled after replication

[Former user]

1. Suppose you have a template with an explicit job requirement of the form SomeCapability exists.
2. Then in some plan you narrow down this requirement to SomeCapability matches regex.
3. After replication you'll get bot of them. Which is not a valid case from the Bamboo point of view (you can't create more than one requirement with the same capability - at least from UI).

I haven't tested other customization cases. But I suggest the capability should be a key and you shouldn't add/overwrite an already existing requirement.

[Hutuleac Iulius]

Hi, I have added a check preventing duplicate requirement creation.

[Andrew Nefedkin]

Thanks, that works fine now.

Only one thing. It looks strange to me that such a replication only occurs if Template Tasks Definition is checked. Those are explicit requirements and they do not deal with any tasks.

[Hutuleac Iulius]

Hi Andrew,

that works as designed. I never encountered such scenario like yours but give me a bit of time, I will see how I can decouple.

Julius

[Hutuleac Iulius]

Ok Andrew,

will publish in a few moments a version that will allow requirement merging without tasks. If tasks are not selected I will merge custom capabilities and skip the task requirements from the template since the task is not copied, no point to copy its requirement.

Does this sound ok to you ?

Julius

[Hutuleac Iulius]

Posted to Marketplace, you can update Andrew.

Julius

[Andrew Nefedkin]

Thank you, Julius for the update.

Unfortunately I can't see any changes in the behavior. Missed requirement doesn't get added.

[Hutuleac Iulius]

Hi Andrew,

I am afraid I dont understand what you would like to achieve in this case.

Can you put in a short description the data, maybe screenshots and what would you expect to get.

Example:

Scenario 1:

Template:

REQ1 = 1

JOB using Template

REQ1 matches .*

After replication JOB should have:

REQ1 matches .*

Scenario 2:

Template:

REQ1 = 1

JOB using Template

REQ1 undefined

After replication JOB should have:

REQ1 = 1

Julius

[Hutuleac Iulius]

Hi Andrew,

or did you mean you disabled the tasks replication and requirement replication is still not happening even after updating the plugin ?

Julius

[Hutuleac Iulius]

Hi Andrew,

had another review of the code, found one small issue that might have blocked requirement replication when tasks are not replicated.

I published a new version, I hope this is what you actually needed.

Julius

[Andrew Nefedkin]

Hi Julius.

Well... yes and no. Now it is even worst. Explicit requirements are OK, but all implicit reqs are completely vanished!

[Andrew Nefedkin]

Another one caveat exists.

If there are two tasks in a job which have the same requirement then after replication only one of them remains.

Please note: implicit requirements are dictated by tasks themselves and never should have duplicated collapsed. Unlike explicit ones.

[Andrew Nefedkin]

I'm afraid current behavior would disappoint users.

Shouldn't there be a new Template Explicit Requirements checkbox alongside the Tasks one?

My current use cases always require to copy them but who knows what other users need?

[Hutuleac Iulius]

Hi Andrew,

lets take it slow then:

explicit you say are ok now implicit functionality should be as follows: - copy only if we replicate the actual tasks - retain requirements of job tasks

Julius

[Andrew Nefedkin]

You are right. And do not touch implicit reqs in case tasks are not replicated.

[Hutuleac Iulius]

So you would like me to revert the change and only replicate requirement when tasks are replicated, as in the original ?

[Andrew Nefedkin]

Hmm, to me the ideal scenario wold be as following:

1. Explicit requirements are always replicated (unless we have a separate checkbox which controls this). Overwrite or merge is controlled by existing checkbox Merge Job Requirements. Do not produce duplicates of a capability.
2. Implicit requirements a replicated as it was before the changes: thus controlled by Template Tasks Definition and Merge Job Requirements. All of them, even having duplicate capabilities.

[Hutuleac Iulius]

Ok Andrew,

will look into it a bit later, few hours.

Julius

[Hutuleac Iulius]

Hi Andrew,

I am still testing various options, it looks good until now.

Until now I tested:

• using manual capabilities and updating them in the jobs making sure they dont get overwritten from templates
• plugin requirements replication from template when task replication is enabled
• disabling tasks in templates, making sure requirement is not affected in the jobs, if task is still enabled in the job
• disabling requirement replication and enabling task replication only, ensuring requirements are replicated in this case

Seems I took requirement replication a bit too lightly in my original design, there are a lot of scenarios.

Feel free to update and test on your setup also.

Julius

[Andrew Nefedkin]

Hi Julius.

Still some bad news after testing the latest version. Let me illustrate with some screenshots this time.

#Plan 1# ##Tasks## ##Requirements tab after replication##

#Plan 2# ##Tasks## ##Requirements tab after replication##

As you can see, identical implicit requirements from tasks of the same type but with different names are cut off - only one of them exists.

Explicit requirements replication seems to be OK.

[Hutuleac Iulius]

So one case left it seems, how to handle duplicate requirements. In your case Plan 1 is the template and Plan 2 is the copy ?

At the moment there is one filter left for duplicates, I am attempting to ensure the job existing requirements do not duplicate template requirements but for some reason is not working for you, something like:

newreqs = templatereqs + (jobreqs-templatereqs)

I will try to recreate your entire build plan later today with template and child and see how I convince it to copy the duplicates.

Julius

[Andrew Nefedkin]

In your case Plan 1 is the template and Plan 2 is the copy ?

No, they are both real plans each having their own templates (different).

[Hutuleac Iulius]

Ok,

so it means the duplicate filter is impacting you. I will have a look, I tough I included in the compare every single attribute but seems I missed something.

Or the requirement is perfectly identical just the task name is different, in that case if you really want the duplicated requirement I can try to allow the duplicates (maybe add a checkbox)

Julius

[Andrew Nefedkin]

I will try to recreate your entire build plan later today with template and child and see how I convince it to copy the duplicates.

But notice these plans have Template Tasks Definition switched off. Therefore implicit requirements shouldn't be touched at all.

Or the requirement is perfectly identical just the task name is different

Yes, you are right.

in that case if you really want the duplicated requirement

This is not my case but rather the Bamboo behaves that way. If I go to the tasks and re-save them then there are "duplicates" from all tasks appear.

[Hutuleac Iulius]

I noticed the tasks are untouched.

I will try to allow those particular duplicates as the original is from another taskId within same job.

Julius PS: I should make a slack :)

[Hutuleac Iulius]

Hi Andrew,

I am sorry to inform you that will take me a bit more time, everything I try in order to allow those duplicates ends up in disaster :)

Worst case scenario I will have to calculate the requirements on my own rather then replicating them, about 2-3 days of work I would estimate.

Julius

[Hutuleac Iulius]

Hi Andrew,

I published a new release, I ended up rewriting the whole requirement management. The explicit requirements are merged and never overwritten in jobs. The implicit task related requirements are no longer replicated but recalculated from scratch.

This seems to be the only way to get a clean set of requirements, replication in this case is not possible.

Best regards, Julius

[Andrew Nefedkin]

Hi Julius.

Sorry for delay.

Now it seems to be all OK. At least nothing has been lost after replication.

Thank you very much.

[Hutuleac Iulius]

No, thank you Andrew, your input is very appreciated.

If you need any further assistance don't hesitate to contact.

Julius