QOps-Build

Builds the applications from the available source files.

Syntax

QOps-Build [-Filter] [-Path] [-Sort] [-Reload] [-Inplace] [-UseBuildDiffs ] [-SetOwner] [-IncludeBookmarks][-AllBookmarks][-Profile] [-Verbose] [-Force] [-New]

Parameters meaning:

-Filter overrides parameters for selecting Applications to process with QOps, allows filtering by following:

• Application Name
• Application Id (OriginAppId or TargetAppId, see QOps-SetLocalApp for details)
• Application Owner
• Application Stream

The multiple masks are supported in a way of repeating the field identifier with a semicolon separator, ex.:-Filter "Name=*ibcs*;Name=*api*,Id=*,Owner=*,Stream=*"

The Semicolon defines result joining with OR logic, the Comma defines results joining with AND logic. When the field name is omitted all possible values for this field will be applied.

-Sort specifies parameters for sorting applications to process with QOps, ex. -Sort "Name=Asc". Allows filtering by following:

• Application Name
• Application Id
• Application Owner
• Application Stream

-Reload triggers reloading of the successfully built application

-Inplace defines that application will be updated keeping existing data without reloading

-Profile overrides default User Profile with the specified one

-Verbose enables extended command line output

-UseBuildDiffs uses differences in the Git repository to build only the changed files

-SetOwner sets the owner of the application

-IncludeBookmarks builds an app with unpublished bookmarks.

-AllBookmarks builds an app with all bookmarks.

-Force skips the confirmation QOps asks for before processing more than ten applications. Without it, a run that matches more than ten applications stops and waits for a typed answer, so scheduled and scripted runs should pass -Force.

-Path limits the run to the objects under one path, glob or single file inside the application's -prj folder — for example a folder such as Dimensions, a single object such as Sheets/<id>, or a pattern such as Variables/v*.

Inside the path the build is a full sync, deletions included: an object you deleted on disk is deleted in the application. Outside it, nothing is touched.

A scoped build acts on an application that already exists, and only ever edits the application it names — it never creates one and never leaves a copy behind. Where it cannot do that it is skipped, with the reason, rather than building something else: the application does not exist yet, it is published, or it belongs to somebody else. On Qlik Cloud there is a fourth case — the application lives in a space and you did not ask to publish, where building would produce a copy and leave the named application untouched.

A scoped build does not push the application's description or thumbnail, which live in App.yaml outside every object folder. Name App.yaml in the path when they are what you want to move.

Matching ignores case and accepts either slash. On QlikView the switch is refused with a message rather than accepted and ignored.

-New — turn it on to create new Qlik applications for folders with missing or unmatched Ids. Folders whose application is already on your Qlik are skipped, each with a line saying so, so the run never writes into an application that is already there. Without -New the run is an ordinary build: existing applications are built and a folder naming no Id is skipped.

Creating an application also records an Id in App.yaml/App.json if it was missing or empty, so every later command addresses it like any other application. The value recorded is the repository's own identity - the project folder name - rather than the Qlik application id. The Qlik id stays in App.local, one per environment, so a repository that creates an application is not tied to the Qlik it was created on.

Shared and managed spaces on Qlik Cloud

This section is about Qlik Cloud only.

QOps-Build writes into an application that sits in no space and is owned by the account QOps connects as — in practice, your own personal space. An application that lives in a shared or a managed space is not written in place: the build creates its own copy in your personal space, writes there, and leaves the application in the space exactly as it was.

That is what the command is for rather than a limitation of a particular run. Building is the step you take while the work is still yours; putting it in front of other people is a separate and deliberate one.

There are two ways you arrive at that copy, and both are ordinary:

• You prepared from an application in a shared or managed space. The first build creates the copy and records it in App.local. Every build after that goes into the same personal application — there is nothing to repeat and nothing to undo.
• You pointed App.local at an application in a shared or managed space, with QOps-SetLocalApp for instance. The next build does not write into it: it creates the copy and rewrites App.local to name the copy. From that point you are in case 1, and the id you set by hand is no longer the one in the file.

Either way App.local is the record of where the build actually went, which makes it the file to read when you want to know which application this repository is bound to right now.

Putting the work into a shared or managed space is the other half, and two commands do it: QOps-Publish, and QOps-Release, which builds and publishes in one run. Those two are the only ones that write an application from the repository into a space.

An application owned by somebody else is copied for the same reason and in the same way.

Sheet visibility on Qlik Cloud

A sheet is published on its own on Qlik Cloud, whether or not the application is — that is what the sections in the sheet list are: a published sheet sits in Public, an unpublished one in My own. A build applies the Published value each sheet carries in the repository, so a sheet you published before you prepared the application is published again in the application the build writes into — you do not have to republish it by hand afterwards.

It works the same way in both directions. A sheet whose repository file says Published: false is made private if it is public on the server, and one that says Published: true is published if it is private.

Two things to know before you rely on it:

• Approved is not applied on Qlik Cloud. Qlik Cloud has no approve operation for a sheet at all, so the value is read and written in the repository but cannot be sent to a tenant. Published is what moves a sheet between My own and Public, and it is applied.
• A sheet that is approved but not published has its Approved value cleared when the repository is written, because approval only means something for a published sheet.

If the sheets in a repository were prepared by QOps 3.0.16 or earlier from an application in a personal space, check their Published values before your first build with this version. Those versions did not report the server's state for such an application, and a build now applies what the files say.

Examples

QOps-Build

QOps-Build -Filter "Name=*project2*;Owner = username1,Stream = Everyone"