Deploying Aggregate 3 CLI when using Azure DevOps Server locally

[gubin-i-da]

Hello!

As I said earlier, a project is uniquely identified when deployed locally by three parameters: <host dns>, <collection name>, <project name>. Following your advice, I was able to successfully connect using the logon.ado command by specifying the url as https://<host dns>/<collection name>/. I hope this will be enough for further work.
But it's hard to understand from the description that the url should be used in this way.
Since the collection must be required specified in identification of concrete project, I suggest adding this to the description.

Currently the description
https://tfsaggregator.github.io/docs/v3/commands/authentication-commands/#logonado
is:
--url -u Account/server URL, e.g. myaccount.visualstudio.com.

p.s.
I crossed over to here from discussion.

[gubin-i-da]

Can I use the features that were defined in tfs aggregator 2 when defining rules, namely: macro snippets or functions?

https://tfsaggregator.github.io/docs/v2/using/scripting/
"You can make your code more modular, using macro snippets or functions."

[giuliov]

No: we had to reimplement from scratch the language and libraries, so we could not bring everything over.

[gubin-i-da]

When deploying the docker image, I found that one of the volumes is the path to the rules folder. Do I understand correctly that eventually all the rules defined in the CLI end up in this folder? I have a question, how does the CLI learn about the web service to which it subsequently passes the rules, by some kind of hidden search on the network, or do you need to specify its url in the some settings?

After a cursory review of the description, for some reason I didn’t found that it to do need in some settings.

[giuliov]

The docker image is a bit new so I am sure that docs can be improved (PRs welcome). You can use only a few of the CLI commands (login, invoke, map). As for the rules you just drop the files in the volume and they are picked up when the rule is first invoked.

[gubin-i-da]

Tried to use logon.env and defined three environment variables AGGREGATOR_AZDO_URL, AGGREGATOR_AZDO_MODE, AGGREGATOR_AZDO_TOKEN. After running the command, I get errors by as I add the environment variables (AGGREGATOR_CLIENTID, AGGREGATOR_CLIENTSECRET) unnecessary for the local mode, filled with the value "x":
"Invalid azure credentials: Value cannot be null. (Parameter 'clientId')",
"Invalid azure credentials: Value cannot be null. (Parameter 'clientSecret')",
"Invalid azure credentials: 'authority' Uri should have at least one segment in the path (i.e. https://<host>/<path>/...) (Parameter 'authority')"

It looks like, that logon.env is not yet usable in local mode.

[giuliov]

It could be. I added Local mode after completing the Azure Function scenario. Thanks for your contribution

[gubin-i-da]

Giulio you did a great job! Till I will use logon.ado.

What about leave only logon.ado with parameters that can be filled with default values ​​from environment variables and that can be replaced with other values ​​by specifying them when calling the command.

p.s.
Ideal projects are always already morally outdated.

[gubin-i-da]

Hello!

I have a question regarding the TransitionToState() method that was in TFS Aggregator. I didn't find it in Aggregate 3 CLI. Does this mean that in order to change the state, I just need to set a new value in the State property from the WorkItemWrapper type? Or should I use something else?

[giuliov]

It is implemented in the next version (you can find the source in the release/next branch). I haven't released it because of issues with integration tests.
Basically, the tests run fine on my machine, but they fail in GitHub Actions.

[gubin-i-da]

Thanks, I'll definitely take a look.

On my computer solution is being built with sdk of version not 6.0.201 but 6.0.400 (file global.json).
Here
https://dotnet.microsoft.com/en-us/download/dotnet/6.0
sdk 6.0.201 exists in build 6.0.3 but last is 6.0.8.
It might be worth update the sdk on the build computer to the latest version?

[gubin-i-da]

Hello!

When approximately is the next version expected to be released?

I noticed that whitespaces cannot be used in the declaration of directives with commas and the "=" sign. The validation of the directives in this case falls. Also, empty lines or lines with spaces are not allowed between directives. Empty string regarded as the beginning of the code.

These nuances are not obvious. It would be worth paying attention to them in the description. Alternatively, blank lines that begin with a directive verb and whitespaces in directive definition can be done as available in the scope of directives.

[gubin-i-da]

In all examples, the rules return a string. It is necessary? How is the returned string value used?

[giuliov]

Yes, it is required.
Value isn't used per-se: it is logged on the webhook response message, helping the Azure DevOps administrator troubleshooting even without access to Azure resources.

[gubin-i-da]

Thank you!

I propose to add this to the description of the rules, since it is not obvious and not everyone will pay attention to the fact that they always return a string in the rule examples.