Deployment Options

With deployment options you can influence the deployment behavior. For example, whether test users should be deployed, in which process model version the Axon Ivy project should be installed. All options and their detailed description are defined in the following deploy.options.yaml.

 1# Example of a deployment options file.
 2
 3# The deploy.options.yaml can be placed at the following places:
 4# 
 5# Prio 1:
 6# As part of your application zip in the root of the application zip. In this case the 
 7# deploy.options.yaml must start with the name of the file to deploy
 8# e.g. myProject.iar.options.yaml
 9# 
10# Prio 2:
11# As part of the project (iar) itself. If you place a deploy.options.yaml. You can
12# place the deploy.options.yaml in the root of the project.
13#
14# It's important to known that only one deploy.options.yaml is in charge for the
15# whole deployment. In an application zip you can not provide a deploy.options.yaml
16# for each single ivy project. If you provide deploy.options in the Engine-Cockpit
17# UI they will have the highest priority. If you provide deploy.options via the
18# REST-Endpoint they also will have higher priority.
19#
20
21# Indicates whether project test users should be deployed or not.
22# AUTO:  Users will be deployed only in demo mode.
23# TRUE:  Users will be deployed.
24# FALSE: Users will not be deployed.
25deployTestUsers: AUTO
26
27# Options to where the project should be deployed to. 
28target:
29
30  # Process model version (pmv) to choose in which the project should be deployed in.
31  #
32  # AUTO:           It will read the version from the pom.xml and will try to find the
33  #                 process model version with that version. If one exists, it will
34  #                 override the currently deployed one. If it does not exist, one will
35  #                 be created.
36  # RELEASED:       Overwrites the current released process model version. If it does
37  #                 not exist, one will be created.
38  # {version}:      It will create automatically a range [{version},) e.g. [2.0.0,). It will
39  #                 search for the latest process model version in that range and deploy it in this
40  #                 process model version. The process model version will be updated with version
41  #                 from the pom.xml. Not recommended - unexpected behavior if you deploy the same 
42  #                 multiple times. 
43  # {versionRange}: Works like AUTO but will search for a process model version which
44  #                 matches that range e.g. (2.0,3.0]. It will
45  #                 search for the latest process model version in that range and deploy it in this
46  #                 process model version. The process model version will be updated with version
47  #                 from the pom.xml. Not recommended - unexpected behavior if you deploy the same 
48  #                 multiple times.
49  # Recommendation: Use AUTO and keep your pom.xml synchronized with the process model version deployed.
50  version: AUTO
51
52  # Defines the state of the process model version in which the project will be
53  # deployed to.
54  #
55  # ACTIVE_AND_RELEASED: Process model version will be actived and released.
56  # ACTIVE:              Will make it active but will not release it.
57  # INACTIVE:            Will make it inactive.
58  state: ACTIVE_AND_RELEASED
59
60  # Whether the project should be packed (as iar) or expanded (open folder) on the
61  # file system.
62  #
63  # AUTO:     Automatically decides based on how it is currently deployed. If it's not
64  #           deployed it will choose PACKED.
65  # PACKED:   Project will be deployed as iar. Packed projects are much better in terms
66  #           of performance. 
67  # EXPANDED: Project will be expanded as open folder. This is deprecated and will be
68  #           removed in future due performance issues.
69  fileFormat: AUTO