9.5 - Continuous Integration Continuous Integration — Knowledge Base articles. Continuous Integration Knowledge Base Overview Continuous Integration Knowledge Base Overview Use CI knowledge base content for maintained automation workflows that trigger or support AIQ executions from CI/CD systems. Recommended guidance Keep CI articles focused on supported tools and current workflows. Use approved credential and secret-management patterns. Record execution IDs, build URLs, artifacts, and logs for traceability. Consolidate duplicate Jenkins, GitHub Actions, and integration examples. Validation workflow Identify the CI system and supported use case. Validate the workflow in a non-production environment. Capture AIQ execution and CI build evidence. Update troubleshooting notes when failures are environment-specific. Last updated: September 20, 2026 AIQ CI/CD Overview Recommended guidance Use AIQ CI/CD integrations to run controlled Scenario Editor, Service Suite, and performance checks from automated delivery pipelines. CI/CD jobs should provide repeatable execution, clear pass/fail criteria, and useful evidence without exposing credentials or customer data. What to define before automation The AIQ environment, project, scenario or suite, target Test Node, and browser or API execution mode. The pipeline trigger: pull request, merge, scheduled run, release candidate, or production validation. The test data source, expected result, timeout, retry policy, and artifact retention. The credential model, using CI/CD secret storage instead of hard-coded values. The owner responsible for failures, flaky tests, and pipeline maintenance. Recommended pipeline behavior Run a small smoke suite before expensive end-to-end or performance suites. Fail the pipeline when AIQ cannot start, times out, or returns a failed result. Publish links to AIQ executions, logs, reports, screenshots, and service responses. Separate product failures from environment, data, browser, and integration failures. Review duplicate or obsolete CI/CD jobs regularly and retire unused jobs. Last updated: October 5, 2026 Update CI/CD Dashboard Code Location for AIQ 5.x Recommended guidance This article is version-specific to AIQ 5.x environments. Use it only when maintaining an AIQ 5.x CI/CD dashboard or migrating an older dashboard configuration. For newer environments, confirm the current dashboard and repository structure before applying these steps. Before changing code locations Confirm the exact AIQ version, dashboard version, repository, branch, and deployment path. Back up the current dashboard configuration and document the previous code location. Check pipeline variables, environment files, service accounts, and artifact paths. Confirm permissions for the CI/CD runner and any service that reads dashboard code. Test changes in a non-production environment first. Validation checklist Run the CI/CD job that publishes or refreshes the dashboard. Confirm the dashboard reads from the new code location. Verify links to AIQ executions, reports, and artifacts still resolve correctly. Review logs for missing files, permission errors, or stale cache references. Document the final path and rollback instructions. Obsolescence note: If the AIQ 5.x dashboard is no longer in use, mark this page as legacy or consolidate the relevant migration note into the active CI/CD documentation. Last updated: October 5, 2026 Bamboo CI Integration with AIQ Dashboard Creation Last reviewed: September 24, 2026 Use this article when Bamboo triggers AIQ execution and the pipeline also needs to publish or create dashboard evidence. What changed in this article Confirm whether Bamboo is still the active CI tool for the customer; many teams have moved this workflow to Jenkins or another CI service. Keep Bamboo plan variables separate from AIQ credentials and dashboard names. Validate dashboard creation with one controlled build before enabling scheduled or branch-wide runs. Validation workflow Review the Bamboo plan variables used to call AIQ. Run a single build and confirm the AIQ execution completes successfully. Verify that the expected dashboard is created or updated with the correct run data. Review note: Marked Bamboo as customer/environment-specific CI guidance and tightened the scope around dashboard creation. Last updated: September 24, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Troubleshoot Linux Environment Issues for AIQ CI Last reviewed: September 30, 2026 Use this article when AIQ executions or CI jobs fail because of Linux host, browser, display, dependency, permission, or environment configuration issues. What changed in this article Fixed the duplicated title “Issues with Linux Environments Issues with Linux Environments.” Reframed the content around AIQ CI and Linux execution-host troubleshooting. Added checks for browser dependencies, display/headless settings, filesystem permissions, environment variables, network/proxy configuration, and logs. Validation workflow Collect the CI job log, AIQ/Test Node log, browser log, and host package/runtime versions. Check Linux display/headless configuration, permissions, dependencies, proxy/network access, and working directory paths. Run a minimal scenario on the same host before changing the full CI pipeline. Review note: This page now removes duplicate title noise and gives a concrete Linux troubleshooting path. Last updated: September 30, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Using Appvance AIQ with Docker/Containers What is Docker? Docker is a container management service that allows developers to build applications, ship them into containers and run them anywhere. What is a container? Is the encapsulation os an application with it dependencies, appears to be a lightweight form of virtual machine (VMs). Facts about containers Share resources with the host OS (more efficient). Can be started and stopped in a fraction of the time a virtual machine would do it. Incurs into little to no overhead compared to applications running natively on the host OS. Allows changes in the running environment easily. A developer can run dozens of containers at the same time, making it possible to emulate a production-ready distributed system. Allows run complex applications without needing to spend hours of configuration and installation issues or worrying about the changes required for their system. This concept is not new, it's an old concept in UNIX systems, they had the chroot command, there have been different implementations across the time and different distributions. coming to what we are discussing today. Docker Hub Get started by downloading Docker Desktop, and learn how you can build, tag and share a sample image on Hub, please take a look to https://hub.docker.com/, create an account and log in, you will find an enormous number of public container images for download, avoiding duplicates work already done by others; in our case could use one of those images as the base to create a new one for AIQ. Docker philosophy "Batteries included but replaceable", meaning that a complete solution would be provided, but parts could be swapped out. One of the biggest use cases and strongest drivers behind the uptake of containers are microservices. Installing Docker The official way to install docker as below. $ culr http://get.docker.com > /tmp/install.sh A good install practice is checking the changes to be performed, do it as below. $ cat /tmp/install.sh Change the access permission for /tmp/install.sh. $ chmod +x /tmp/install.sh Issue the script file as below $ /tmp/install.sh A few checks, then install docker using the appropriate package for your system, this documentation does not include the installation procedure for Windows platforms, there are a lot of considerations beginning by Docker is native for Unix alike systems and there are not strong implementations and experiences in Windows. In case of Red Hat based distributions, it is recommended you run SELLinux in permissive mode, which will log rather than enforce errors, check mode by issuing as below. $ sestatus If the current mode is "enforcing" then change into the permissive mode as follows. $ setenforce 0 Additional tasks As Docker is a privileged binary, it will need to prefix commands with sudo to avoid that add the current user to the docker group as follows. $ sudo usermod -aG docker The last command is for Ubuntu but would be similar for other Linux distributions, now restart the Docker service by performing. $ sudo service docker restart In order to test that the Docker has been properly installed run the command as follows. $ docker run debian echo "hello world" Some verbosity will be obtained, the last line must be "hello world" Building images from Dockerfiles Dockerfile is a plain text file containing instructions to create an image, a Docker image is a file, comprised of multiple layers, used to execute code in a Docker container. Most common instructions are: FROM, specify the base image to use, the format for this instruction is "FROM :" latest version will be used if no version is specified e.g. (FROM ubuntu:18.04) WORKDIR, specify the default folder in the container. ENV, specify environmental variables in pairs e.g. (ENV folderTemp /tmp) LABEL, customized labels e.g. (version=1.0) EXPOSE, informs Docker that the container listens on the specified network ports at runtime e.g. (EXPOSE 80/tcp) USER, sets the user name (or UID) and optionally the user group (or GID) to use when running the image and for anyRUN,CMDandENTRYPOINTinstructions that follow it in theDockerfile e.g. (USER patrick) VOLUME, creates a mount point with the specified name and marks it as holding externally mounted volumes from native host or other containers, these volumes will persist the data. COPY, This copies one or many local files or folders into the destination within your Docker image e.g. (COPY Gemfile Gemfile.lock ./) ADD, same that COPY but additionally If is a local tar archive in a recognized compression format, then it is automatically unpacked as a directory into the Docker image. e.g. (ADD rootfs.tar.xz /) RUN, executes the command(s) that you give in a new layer and creates a new image. This is mainly used for installing a new package, e.g. (RUN apt-get update && apt-get install -y apache2) ENTRYPOINT, Entrypoint sets the command and parameters that will be executed first when a container is run, e.g. (ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"] CMD, The main purpose of a CMD (Dockerfiles) / command (Docker Compose files) is to provide defaults when executing a container. These will be executed after the entrypoint. There are more instructions and details over this stuff, but this document is not intended to be a Docker course but the necessary tools to implement AIQ in containers. Best Practices Needs to be easy to destroy. One service per container. Avoid undesired files by declaring them in .dockerignore file. As few layers as possible. Use multiline in instructions for readability and layers reduction. Have the more arguments as possible. Avoid installing unnecessary packages. Adding labels that help and guide the usage. Last updated: May 17, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Run AIQ Workflows from GitHub Actions Run AIQ Workflows from GitHub Actions Use GitHub Actions to orchestrate AIQ-related workflows only when repository, credentials, environment, and execution permissions are approved. Recommended guidance Store secrets in approved GitHub Actions secret management. Parameterize environment, branch, suite, and execution profile values. Avoid writing tokens, logs with secrets, or internal URLs into public workflow output. Record GitHub run URLs with AIQ execution evidence. Validation workflow Create or update the workflow in a non-production branch. Run a validation workflow with safe parameters. Confirm AIQ execution or integration behavior. Document failures with the GitHub run URL, logs, and AIQ execution ID. Last updated: September 20, 2026 Run AIQ Tests with GitHub Actions CI/CD Last reviewed: September 22, 2026 Use GitHub Actions to trigger AIQ executions from a repository workflow and publish the result back to the pipeline. Recommended guidance Store AIQ tokens and environment values in GitHub Actions secrets. Pass scenario, project, dataset, and environment parameters explicitly. Use quality gates so failed AIQ executions fail the workflow when appropriate. Validation workflow Create or update a workflow YAML file for the target branch or release event. Add a step that authenticates to AIQ using approved secrets. Trigger the AIQ execution through the supported CLI or API for your version. Capture execution ID, report URL, and result status as workflow output. Fail or pass the job based on the agreed threshold. Note: Do not print credentials or tokens in GitHub Actions logs. Last updated: September 22, 2026 If you have feedback on this topic, contact documentation@appvance.ai. How to consume scenario into the dashboard Unzip the files that are available (That we got by making use of CreateScenarioDashboard ant call) edit the build.xml: change product property value change environment property value change project property value change the customer property value change bucket property value RMScenario1: run ant report1 RMScenario2: run ant report2 Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Link Jenkins Jobs for AIQ Workflows Link Jenkins Jobs for AIQ Workflows Link Jenkins jobs when an AIQ workflow requires a controlled sequence, such as build, deploy, test execution, and report collection. Recommended guidance Use explicit parameters between jobs instead of hidden environment assumptions. Fail fast when an upstream job fails or produces invalid artifacts. Record build URLs and AIQ execution IDs for traceability. Avoid passing secrets through plain-text parameters or logs. Validation workflow Define the upstream and downstream job responsibilities. Pass only required parameters or artifacts. Run a validation chain in a non-production environment. Review logs and AIQ output before using the chain for scheduled runs. Last updated: September 20, 2026 Move or Relocate AIQ Dashboard Projects Move or Relocate AIQ Dashboard Projects Move or relocate dashboard projects only through approved project-management or migration procedures so reports, permissions, and references remain consistent. Recommended guidance Confirm project owner, destination, access, and retention requirements. Back up or export required data before a migration. Check linked executions, dashboards, reports, and integrations after the move. Document the old and new locations for support and auditability. Validation workflow Plan the move with the project owner. Perform the move in the approved environment or maintenance window. Validate dashboards, permissions, and report links. Record migration evidence and follow-up issues. Last updated: September 20, 2026 Questions on Jenkins Server Questions on Jenkins Server Regarding the test execution machine to trigger build XML for the dashboard (2 Core and 8GB for Jenkins, with ant and git plugin), can this be shared for different teams/applications? Can you also confirm, that this machine will have a copy of the automated scripts? And if this is shared with different application teams, everyone will have access to the test scripts for all applications? Responses - 1- Yes, it can be shared with different applications or teams, just change the product/environment to differentiate results. 2- Workspaces are created for each pipeline, and it gets saved there as a temp folder right and we don't know how long it stays there is a plugin called workspace clean up plugin, that can be configured to clean up workspaceshttps://computingforgeeks.com/automatically-clean-up-jenkins-workspace-after-builds-complete/#:~:text=Login%20to%20Jenk[…]20tab%20below%20the%20page 3- yes, I think everyone will have that access, again depends on 2 Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Parameterize the AIQ Controller URL in a GitLab CI/CD Pipeline Parameterize the AIQ Controller URL in a GitLab CI/CD Pipeline Parameterize the AIQ Controller URL so the same GitLab CI/CD pipeline can run against different AIQ environments without changing the pipeline script for every deployment. Recommended approach Store the Controller URL as a GitLab CI/CD variable instead of hard-coding it in the pipeline file. Use separate variables for development, staging, and production-like AIQ environments. Keep authentication tokens and credentials in protected or masked variables. Validate the URL before triggering a long-running suite so failed configuration is caught early. Pipeline checklist Define the Controller URL variable in GitLab settings or the pipeline environment. Reference the variable from the AIQ execution command or integration script. Run a small smoke test to confirm the pipeline reaches the intended controller. Review logs to make sure sensitive values are not printed. Promote the same pipeline definition across environments by changing only variable values. Last updated: October 8, 2026 Run AIQ on Windows as a Service Recommended guidance Run AIQ on Windows as a service only when the deployment model and support plan require it. Service configuration should define the service account, startup behavior, logging, recovery, permissions, and upgrade process. Pre-checks Confirm the Windows version, AIQ version, install path, Java/runtime requirements, and service account. Grant only the permissions needed for AIQ files, logs, repositories, browsers, and network access. Confirm antivirus, firewall, proxy, and certificate policies allow required AIQ operations. Define restart behavior and monitoring alerts. Validation workflow Start and stop the service from the approved service manager. Confirm AIQ is reachable after restart and after host reboot. Review service logs, Output Logs, and Windows Event Viewer for startup errors. Run Scenario Editor and Service Suite smoke tests after service changes. Last updated: October 6, 2026 Legacy Bamboo CI Setup for AIQ Execution Last reviewed: September 29, 2026 This page is retained for teams that still run AIQ execution plans from Atlassian Bamboo. What changed in this article Marked Bamboo CI setup as legacy/environment-specific because many current CI workflows use Jenkins, GitHub, Azure DevOps, or another maintained runner. Replaced the long Bamboo installation walkthrough with targeted AIQ execution-plan guidance: agents, Ant tasks, repositories, credentials, and result handling. Called out stale dependencies from the old article, including Ubuntu 16.04, Oracle JDK 8, old Bamboo agent versions, and credential files such as creds.json. Validation workflow Confirm Bamboo is still the customer’s active CI system before using this page. Validate agent OS, JDK, Ant, browser, repository, and AIQ connectivity before creating the execution plan. Run one controlled Bamboo build and confirm AIQ execution results are created before scheduling recurring jobs. Review note: Kept as legacy CI guidance and removed the impression that old Bamboo/JDK/Ubuntu setup is current default practice. Last updated: September 29, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Troubleshoot Jenkins Out-of-Memory Failures Troubleshoot Jenkins Out-of-Memory Failures Use this checklist when a Jenkins job that supports AIQ workflows fails with an out-of-memory error. Recommended guidance Separate Jenkins controller, agent, build tool, Java, and test-process memory symptoms. Review recent changes in dependency size, test volume, browser count, or artifacts. Avoid simply increasing memory without identifying the failing process. Capture Jenkins logs, build URL, and related AIQ execution IDs. Validation workflow Identify the exact process reporting out-of-memory. Review heap, container, agent, and build-tool settings. Run a smaller validation job to isolate scale-related failures. Apply the smallest safe configuration or workload change and document the result. Last updated: September 20, 2026 CI/CD Dashboard Credential Encryption Recommended guidance Credential encryption for CI/CD dashboards protects sensitive values used by automation. Treat this page as security-sensitive guidance: never paste real passwords, tokens, keys, or decrypted values into documentation, tickets, chat, or screenshots. Recommended controls Store secrets in approved secret managers or CI/CD credential stores. Encrypt values before they are committed or shared with deployment artifacts. Limit decryption capability to the runtime or owner that actually needs it. Rotate credentials when ownership, access scope, or exposure risk changes. Audit who can view, edit, or deploy encrypted dashboard configuration. Validation checklist Confirm the dashboard can read encrypted values at runtime. Confirm logs do not print decrypted credentials. Test failure behavior when a credential is missing, expired, or revoked. Document rotation and emergency revocation steps. Last updated: October 6, 2026 Encrypting EC2 Cloud Configuration Files using API Calls