--- title: Excluding objects from continuous integration related: - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration.md - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md - https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md --- > Agent instructions: > **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown. > > - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version. > - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt). The [continuous integration solution](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration.md) allows you to exclude specific types of objects if you do not wish to synchronize all supported types. You can also exclude individual objects of a type that is otherwise included. All related configuration is defined within the **repository.config** file in the root of the _CMS\App\_Data\CIRepository_ folder (or another location set by the _CMSCIRepositoryPath_ web.config key). Use the following process if you need to make any changes: 1. Edit the **repository.config** file. 2. Adjust the configuration according to your object filtering requirements. See the following sections for details: - [Excluding object types](#excluding-object-types) - [Excluding individual objects](#excluding-individual-objects) 3. Save the _repository.config_ file. 4. Run complete serialization for all objects to bring your _CIRepository_ folder into the required state: 1. Disable running of [scheduled tasks](https://docs.kentico.com/13/configuring-xperience/scheduling-tasks.md) (using the **Settings -> System -> Scheduled tasks enabled** setting). 2. Open the **Continuous integration** application in the administration interface. 3. Click **Serialize all objects**. 4. Wait until the serialization process finishes and then re-enable scheduled tasks. Excluding objects in the _repository.config_ file affects all processes related to continuous integration: - Serializing of all objects onto the file system - Automatic tracking of create, update and delete operations for the given objects and transferring of the changes to the serialized data - Restoring of objects from the file system into the database > **Note:** **Important**: To maintain consistency, always use the same _repository.config_ settings across your entire development environment. Whenever you make any changes, use your source control system to synchronize the _config_ file along with the other content of the _CIRepository_ folder. When a developer loads a new version of _repository.config_ from the source control, the new settings start applying after [restoring objects into the database](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md) or a manual restart of the application. > **Note:** **Warning**: Objects excluded in _repository.config_ may still be deleted when restoring data from the file system because of dependencies. For example, even if you have setting keys excluded from continuous integration, the system still deletes setting keys that belong within a given setting category if you "restore" the deletion of the category. ## Excluding object types By editing your application's **repository.config** file, you can configure the system to ignore certain object types within continuous integration: 1. Add **** elements into one of the following sections of the config file: - **** – defines a _whitelist_ of object types. If you specify one or more object types, continuous integration only processes objects of the given type. No restrictions apply if the whitelist is empty. - **** – defines a _blacklist_ of object types. Continuous integration processes all included object types except for the listed types. 2. Set the values of individual **ObjectType** elements to the names of object types that support continuous integration. > **Tip:** **Tip**: To find the _ObjectType_ values, see [Object types supported by continuous integration](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/object-types-supported-by-continuous-integration.md) or check the names of the corresponding folders in the _CIRepository_ folder. The system uses the following rules to automatically exclude child and binding objects: - Child object types follow the configuration of their parent object type. For example if you exclude page types, then queries, transformations and alternative forms of page types are also excluded. - Binding object types are excluded if all object types within the given relationship are excluded. The **** whitelist only allows you to specify the main object types (i.e. not child types or bindings). In the **** blacklist, you can exclude both the main object types and specific binding or child object types. > **Info:** By default, the __ list contains the _cms.settingskey_ object type. Settings may contain sensitive data – only remove the exclusion if you agree to make setting values available within the file system used by your application and any connected source control systems. You can remove the exclusion for settings in general, and add a __ element to exclude individual setting keys that you consider sensitive. #### Examples ```xml cms.emailtemplate ``` ```xml cms.webpart cms.webpartcategory cms.webpartlayout ``` ## Excluding individual objects By editing your application's **repository.config** file, you can exclude individual objects from continuous integration. The system combines the filtering rules for individual objects with any existing rules for entire object types. 1. Add **** elements into the **** section. 2. Specify the type of the objects that you wish to exclude for each __ element: - If you do not set the **ObjectType** attribute for the element, it applies to objects of ALL types. - To apply the filtering rule to a specific object type, set the element's **ObjectType** attribute to the given object type name. - You can use both main object types and child types (that are included in your continuous integration configuration). - Binding types typically do not have a code name field, so cannot be used. - Rules for specific object types override rules for all object types. You can disable rules for all object types by adding empty __ elements for individual object types. - Do not add multiple __ elements for the same object type. Instead, use multiple values separated by semicolons and/or wildcards. 3. Within the content of each __ element, list the **code names** of objects of the given type that you wish to exclude. - To cover multiple objects with a shared code name prefix or suffix, add the % wildcard to the **end or start** of the code name entry. Using only the % wildcard as the value excludes all objects of the given type. - You can add multiple code name entries for a single object type, separated by semicolons. - To exclude pages (the _cms.document_ object type), use **alias path** values instead of code names. This identifies pages based on their location in the content tree. - The code name values are case insensitive. When you exclude an object, the system automatically excludes dependent objects according to the following rules: - **Child objects** – all child objects are excluded with their parent. For example, excluding a country object also excludes all states under the given country. - **Binding objects** – binding objects are automatically excluded if at least one of the related objects is excluded. For example, excluding a user automatically excludes all binding records that involve the given user, such as user-role relationships. - **Site objects** – excluding a site automatically excludes all site-specific objects belonging to the given site. - Does not apply to objects that are only connected to sites through bindings. For example, users can be assigned to sites through bindings, but are still global objects (not excluded along with sites). - **Category hierarchies** – for objects that are organized within categories in a tree hierarchy in the administration interface, excluding a category also excludes all objects in the sub-tree. For example, excluding a web part category also excludes all web parts and sub-categories within the given category. - [UI elements](https://docs.kentico.com/13/custom-development/creating-custom-modules/reference-managing-ui-elements.md) are an exception. Continuous integration does not automatically exclude the entire sub-tree under excluded elements. However, excluding a module also excludes all UI elements that belong to the given module. > **Note:** **Notes** > > - It is not possible to exclude objects without a code name field (except for pages). > - The object exclusion rules apply globally for all sites, even for pages. For example, adding the _/Testing/%_ alias path for pages excludes all pages under the _/Testing_ section on any site in the system. > - When excluding objects that have a defined and significant order, you must always keep excluded objects as last in the order, after the remaining objects. Otherwise you may encounter order inconsistencies when transferring objects between different instances. You may need to manually move excluded objects to the end of the order after [restoring](https://docs.kentico.com/13/developing-websites/setting-up-continuous-integration/restoring-continuous-integration-files-to-the-database.md) new objects from the _CIRepository_ folder. #### Examples ```xml CMSSMTPServerPassword;CMSStagingServicePassword test% /Testing/% ``` ```xml test% /test/% ```