Code compare is really handy when it comes to identify bug or automation breakages. I did see time logs of when which user published to repository, does UiPath orchestrator also have a section where one can review what changes got published between 2 publish?
Because the projects are using XAML which is both made of of content and meta data it can be difficult to compare these files.
Studio has built in Workflow / Project File compare capabilities, but this depends on you looking at local copy of the files and/or to version control such as Git.
In Orchestrator you can browser the Tenant / Host Packages and click on the Explore Package button. From there you can click the Compare button and
From here you can compare the dependencies and workflow of packages in your Orchestrator. I’m not fond of the UI for viewing workflows, but it is somewhat functional
My overall suggestion to tackle this if the source is within your control is to ensure that your have controls in place to enforce versioning/branching/tagging / whatever means that you use and perhaps follow it up with an Artifact Repository so you have immutable packages after they are publish which could be take a step further by signing your packages for authenticity. With that it would be easy to compare package builds outside of UiPath Studio/Orchestrator with whatever VCS that you use.
Thanks @codemonkee for the clarification. I tried pushing UiPath Automation repo to bitbucket and see lots of .object .settings .local and .screenshots folder. Can you please guide me on understanding which files are important w.r.t. project point of view, so that it becomes easy to manage large number of Test Cases?
I’m not as familiar with the new project structures in new versions yet, I would recommend taking the time to search the documentation in reference to each.
Within the following UiPath makes the note
We recommend adding all the files and subfolders in the project folder to source control (the
.local
subfolder is ignored by default). In addition, make sure there are no ignore lists such as.gitignore
files configured in a way that excludes project files and subfolders.
.local
is certainly a good one to ignore as mainly for caching and other bits and bobs that are created over and over locally and would be different from environment to environment between users.
.screenshots
is your screen captures for the UI activities that can be helpful to understand what the workflow or specific activity is doing. However they might contain private information that you may not want in your code repository. In our organization, we leave them in and make reviewing the screenshots part of our code reviews, making sure to remove any sensitive PI and/or cleaning up old screenshots.
.object
I haven’t had a chance to play around with it but more information can be found
.entities
is about using Entities with Data Services more details can be found
.settings
are for your Project Settings. Right click Project Node in the project tab > Project Settings. This is where you control the various Settings/Properties of a given project and their Activities Settings for run vs debug, environments, etc.
I’m sure there are others, but best course is to start with the documentation and if you have specific questions about a particular feature, I’m sure someone in the community can help to clarify.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.