Apply some generic rules at organization level to all projects about aggregator-cli HOT 8 OPEN

You pose two questions:

1. apply a rule to a whole organisation
2. automatically add rules when a project is created

The first answer is yes: you can deploy a single rule and add a mapping to each and every project in the org so they all invoke the same rule. Clearly the rule has to take in consideration the event context (say project A and B do not have the same set of work item types, like an Agile vs Scrum project) to work correctly.
Aggregator has no facility for organisation, you need to invoke it multiple times. I take note and see to add some helpers post 1.0 release.

I am lean to answer no to the second part: TFS/AzDOS have no public event for a new project.
You have two ways to work around this limit:

• or you use a tool that invokes TFS/AzDOS create project API first and then invoke Aggregator to map the rules
• you periodically run a script that looks for new projects and maps Aggregator rules on them

I can help you with directions and I will research if this is the definitive answer.

from aggregator-cli.

After more digging I found a positive answer to the second question: there is a way to be notified when a project is created (or removed). Implementation is non trivial so we will implement it after release 1.0.

Please @KamranAslamBhatti share your thinking; do not close the issue as it will help us track the feature in the backlog.

from aggregator-cli.

Giuliov, Could you please share how can we do the following:

• there is a way to be notified when a project is created (or removed).

Thanks,
Kamran

from aggregator-cli.

As I said, implementation is non-trivial: one should add many things to Aggregator CLI and its runtime. Things that come to mind:

• add support for Project events in CLI map command
• add listener for Project events in Runtime
• expose Project object(s) to Rules (I guess a read-only object suffices, this would avoid managing object caching and updating)

You can submit a PR that implements the above items, I would be delighted to review and merge it.

from aggregator-cli.

@giuliov - Could you point me to where the Project events are? I've been looking everywhere that I can think of to find where you could get notified a project is created and haven't been able to find it. I might be able to start some work around this to get it started.

from aggregator-cli.

I cannot find any notes on the "non trivial" solution and, as I wrote in the initial response, there are no events in public docs.

An idea is to use a Timer binding instead of the normal HTTP binding.
The difference should be confined to the aggregator-function project. I guess it would be better to specialise run.csx per "logical" event type: from FunctionTemplate/run.csx to FunctionTemplates/workitem/run.csx, FunctionTemplates/project/run.csx ecc.
This has a cascade effect: AzureFunctionHandler.RunAsync method cannot retrieve the workitem, the self object in rules is now a project object; probably need some declaration in the rule to prevent mapping errors (a rule designed for project event mapped to a workitem event).
Finally the timer function need some permanent store to note when a project is added/deleted (diff'ing state) and invoke the rule.

We can use Slack for discussing details, if you like the idea.

Also @jessehouwing may have some smart idea on this topic.

from aggregator-cli.

from aggregator-cli.

The audit looks promising. I'll try to play around with it a little.

from aggregator-cli.