Frequently Asked Questions

To check the App Factory version, sign-in to your App Factory console, and then select App Factory Version from the left panel. The App Factory Version page opens, which displays the details such as the App Factory version and plugin versions.

Alternatively, you can open this page by clicking the Temenos App Factory link from the footer at the lower-right corner of the page.

There is no direct dependency with the Visualizer and Fabric versions. If you upgrade your App Factory environment to the latest version, it will continue supporting and building with the Visualizer project version of the app, and will work with the Fabric details that were provided earlier.

App Factory versions are tested on specific released versions of tools and plugins, so you cannot choose to upgrade any part of the configuration due to compatibility issues and security issues.

However, if you notice any errors that are specific to a version of the tools that are being used in your App Factory instance, you can raise a request for assistance on the issue. You can also upgrade the tool version, if required, to resolve the issue.

The following table lists the App Factory releases with the supported Xcode version, and the same versions are provisioned during installation or upgrade.

App Factory supports most of the GIT based source code management tools such as GitHub, Bitbucket, and AWS Code Commit.

You can create two types of triggers by using App Factory.

• A cron-based trigger, which is called a Scheduler, to trigger timely builds for a project.
• A push-based trigger, which is called a Watcher, to trigger builds whenever a commit is pushed to a respective branch.

You can check the details that are printed in the build console log at the build job for every channel.

For example: [INFO] Current Project version: 9.2.0

This issue might occur if the application project is upgraded, but not pushed properly to the Git repository.

After a project is upgraded or imported to a specific Visualizer version, build the app from Visualizer. If the build passes, you need to commit the diff of the workspace content code to your Git repository to trigger the build with App Factory.

Android builds occur on a macOS agent that is hosted on a Cloud infrastructure.

To debug a build failure, you can check the logs of a build in a project by navigating through the respective service:
<project_name> → <service_name> → Builds → <build_job> → <build_number> → Console Log

For example: TestProject → Visualizer → Builds → buildVisualizerApp → #19 → Console Log

You can also click Full Log on the Console Output page to see the whole log. You can search for ERROR statements to easily inspect the build.

1. Go to the build job by navigating by navigating through the respective service:
   <project_name> → <service_name> → Builds → <build_job>
   
   For example: TestProject → Visualizer → Builds → buildVisualizerApp
2. Click the build number of the failed build, and then click Console Output from the left panel.
3. Check the console log for any error that directly or indirectly falls under the configuration issue.
   This includes validating parameters that were entered for a build and any service misconfiguration that is directly indicated.
4. In the section that contains the failed build number, you can view the logs from the Logs link in the description.

   NOTE: This link will be available in the build description of the parent build that triggered a particular child build. Therefore, Temenos recommends always rebuilding the parent build.

5. At least one local build must be performed on Visualizer by using the same source of the application for which the App Factory build failed. Make sure that you cross-verify the commit IDs on the repository and the local source.
6. In case the Visualizer build passes, you can share the Visualizer logs and app binary for debugging while raising an App Factory support ticket.

MustHaves is a zip archive file that contains a set of log files, which are useful for debugging or analyzing build failures. These files are collected during the build process, and if the build was not completely successful, the files are shared as a downloadable link in the build history section with the label Logs.

It generally contains the following set of files: App FactoryVersionInfo.txt, environmentInfo.txt, ParamInputs.txt, vizbuildlog.log. It also contains information about the respective channel and the test-related build logs.

The download links are provided if the build fails after being triggered from the buildVisualizerApp or buildFabricApp page.

As per password reset policy, if you update your cloud login credentials, you need to update the same App Factory credentials that were created for the parameter FABRIC_CREDENTIALS_ID.

To update the credentials, navigate to the App Factory project and click the Credential link on the left panel. You can search and select the credentials from the list, click Update from the left panel, provide the new password, and then save the credentials. The builds that use this credential will use the updated password.

The iOS platform build takes care of standard Xcode build settings by default. If you want to execute custom steps or out of the box steps, you can do so by writing and uploading a custom hook script.

NOTE: The hook script (automation code) must be written on your own and validated on a local Mac device before hooking it into the App Factory build pipelines.

Make sure you have added the recipients address correctly in App Factory. For projects that use version V9SP2 or later, you can verify the recipients address in the Project Settings. For projects that use versions earlier than V9SP2, you must add the recipients address in the RECEPIENTS_LIST parameter of the respective job.

App Factory only sends failure notifications from the channel level jobs to give you direct logs of the failed job for debugging. Therefore, make sure that if your build was successful, you triggered it from the main build job, such as buildVisualizerApp. You can also check your spam for an email from noreply@kony.com.

If you are sure that there is an issue with the mail delivery system of your App Factory instance, you can raise a support ticket to the CloudL2 Operations team.

The artifacts link that is shared through the build email is active for a limited period of time. If you are trying to download the build artifacts from a long time ago (such as one year ago), you are likely to see errors.

You can use the Database service to perform database migrations with the Flyway tool support provided by App Factory. To do so, navigate to your App Factory Project → Database → Flyway, and then select Build with Parameters to trigger a fresh build.

App Factory supports the community edition for Flyway. For more information about the free community version of the tool, visit the Flyway website.

App Factory currently supports MySQL Databases for Flyway.

To create a webhook, you need to have access to the Settings option of repository. If you don’t see the settings, you need to get admin permissions for the repository.