Code analysis enforcement

As an administrator, you can enforce code analysis when developers check in automation files to the public workspace. You can restrict the RPA developers or Citizen Developers from checking in automations that contain code analysis violations based on permissions assigned to them in their custom role.

Code analysis enforcement is based on a combination of the following:
  • Policies applied to folders
  • Permissions allocated to users in their custom roles
Code analysis policies apply to files in the Automation tab. You can configure the same rule with two different policies but with different severity levels; one with low severity and the other with high severity. By using policies with rules configured at different severity levels, you can focus the enforcement to specific automation projects.

enforce code analysis

Code analysis enforcement permissions

The following code analysis enforcement permissions are available:

  • Enable enforcement for bot check-in: A default permission for all roles which allows the user to check in the automation file if it has no code analysis violations.
  • Allow check-in with low severity violations: This optional permission allows the user to check in the automation file if it has low severity code analysis violations.
  • Allow check-in with high severity violations: This optional permission allows the user to check in the automation file if it has high severity code analysis violations.
Important: Starting with Automation 360 v.29, all the system roles (such as AAE_Basic or AAE_Admin) will have only the permissions to check in automation files with no violations. All the custom roles (user-defined roles) are updated to contain both the permissions to check in with low and high severity violations. For enforcement, you should edit your custom roles to restrict check-in. If you use only system-defined roles for your users, to configure enforcement, you must create new roles to assign the appropriate permissions to check in automation files with violations.

Use different roles and permissions to restrict automation file check-in based on the skill level of the developer. For example, you can have policies with low and high severity violations applied to a folder. You might have Citizen Developers who are assigned the permission to check in automation files with both high and low severity violations, whereas the RPA developers might have the permission to check in automation files with no violations or only low severity violations.

You can use different policies on different automation projects and set different rule severity levels for different policies and environments. For example, in the testing environment, you can have policies where all rules are set to high severity, and the RPA developers can only check in automation files with low severity or no violations.

Example

The following example shows three automation files with their code analysis results:
Automation files Code analysis results
File 1 10 rules with high severity violation
File 2 7 rules with high severity violation

20 rules with low severity violation
File 3 10 rules with low severity violation
The example includes three users with assigned roles:
User Role assigned
Alice Role 1
Bob Role 2
Carol Role 1, Role 2
  • Users in role 1 can check in automation files with results of high severity violation.
  • Users in role 2 can check in automation files with results of low severity violation.

The code analysis enforcement for these users are as follows:

  • Alice can check in file 1.
  • Bob can check in file 3.
  • Carol can check in file 1, file 2, and file 3.