fiftyone.geolocation 4.3.1 → 4.3.3

package/ci/common-ci/.github/labels.yml

@@ -16,6 +16,9 @@
 - name: "status: to be scheduled"
   description: This item has not been scheduled for a particular release
   color: c2e0c6
+- name: "status: assigned"
+  description: This item has been assigned to an engineer
+  color: 6ff076
 - name: "status: duplicate"
   description: This issue or pull request already exists
   color: cfd3d7
@@ -31,6 +34,26 @@
 - name: "status: released/4.3.3"
   description: This change was released in the specified version
   color: 006b75
+- name: "status: released/4.3.4"
+  description: This change was released in the specified version
+  color: 99ccff
+- name: "status: released/4.3.5"
+  description: This change was released in the specified version
+  color: ccccff
+- name: "status: released/4.3.6"
+  description: This change was released in the specified version
+  color: cc88ff
 - name: "status: released/4.4.0"
   description: This change was released in the specified version
-  color: 376842
+  color: 376842
+
+  # Scheduled Labels
+- name: "scheduled: 6th Oct 2021"
+  description: This item has been scheduled for 6th Oct 2021 release
+  color: 6ff076
+- name: "scheduled: 20th Oct 2021"
+  description: This item has been scheduled for 20th Oct 2021 release
+  color: 6ff076
+- name: "scheduled: 3rd Nov 2021"
+  description: This item has been scheduled for 3rd Nov 2021 release
+  color: 6ff076

package/ci/common-ci/.github/workflows/sync-labels.yml

@@ -19,6 +19,7 @@ jobs:
           manifest: .github/labels.yml
           repository: |
               51Degrees/caching-dotnet
+              51Degrees/common-ci
               51Degrees/common-cxx
               51Degrees/data-file-tool
               51Degrees/device-detection-cxx
@@ -43,5 +44,6 @@ jobs:
               51Degrees/pipeline-php-core
               51Degrees/pipeline-php-engines
               51Degrees/pipeline-python
+              51Degrees/pipeline-specification
               51Degrees/Renderer
           token: ${{ secrets.LABEL_SYNC_TOKEN }}

package/ci/common-ci/CiTips.md

@@ -2,4 +2,33 @@
 ## Writing Script
 When writing script to perform a batch job, a common bug that happens often is not verifying if a step has successfully completed. There are many instances where an error code is not caught and is subsequently overwritten by the following steps, resulting in a false positive result. Therefore, when writing a script task, the following tips would help to minimize this risk:
 1. Always verify that the result of the script is as expected. Such as checking error code or checking if a certain conditions have been met. This can be done at a number of places in the script where a certain change could impact the final outcome.
-2. Where a required condition was not met, log a message and exit with an appropriate non zero code. This will make sure the exit code will always be caught by the script task.
+2. Where a required condition was not met, log a message and exit with an appropriate non zero code. This will make sure the exit code will always be caught by the script task.
+
+## Using variables from other jobs
+
+When a variable in a separate job, in a separate template is required you may need to output it manually depending on the task that sets the variable.
+
+For example the GitVersion task does not output variables it produces to the pipeline, you must create a separate script task to echo the variable like so:
+
+```yml
+- job: Tagging
+  steps:
+
+  # GitVersion task here.
+
+  # Output the GitVersion.SemVer variable so it can be used in other jobs.
+  - script: echo "##vso[task.setvariable variable=GitVersionSemVer;isOutput=true]$(GitVersion.SemVer)"
+    name: setvarStep
+```
+
+Then you can access the variable in a separate job like:
+
+```yml
+- job: Build
+  dependsOn: Tagging
+  variables:
+    # map the output variable from A into this job
+    varFromTagJob: $[ dependencies.Tagging.outputs['setvarStep.GitVersionSemVer'] ]
+  steps:
+  - script: echo $(varFromTagJob) # this step uses the mapped-in variable
+```

package/ci/common-ci/README.md

@@ -1,6 +1,8 @@
 # Common-CI
 Common-CI project contains a guideline for creation of continuous integration scripts and describes a general approach to continuous integration within 51Degrees. This readme should provide a comprehensive overview of rules and conventions to be expected from existing jobs and which should be followed when new jobs are created.
 
+**NOTE**: A Release Engineer following this guide should first check the `internal-ci` readme to understand the 51Degrees release process.
+
 # Table of content
 - [Common-CI](#common-ci)
 - [Table of content](#table-of-content)
@@ -26,6 +28,10 @@ Common-CI project contains a guideline for creation of continuous integration sc
     - [Packages release](#packages-release)
     - [External package managers and public repositories](#external-package-managers-and-public-repositories)
   - [Automation](#automation)
+    - [Fully automated release process](#fully-automated-release-process)
+    - [Additional pipelines:](#additional-pipelines)
+    - [Updating the Release Configuration](#updating-the-release-configuration)
+    - [Fully automated deployment trigger procedure:](#fully-automated-deployment-trigger-procedure)
     - [Automated Release Scripts](#automated-release-scripts)
     - [Flow Chart](#flow-chart)
   - [Naming convention](#naming-convention-1)
@@ -212,6 +218,9 @@ All of the packages for daily continuous deployment are created based on the lat
 Deployment to internal package managers is performed daily (overnightly) based on changes applied to `develop` branches of the source code repositories. 
 
 ## Release process
+
+Refer to the `internal-ci` readme for instruction on 51Degrees release process.
+
 ### Packages release
 Packages release process in 51Degrees is handled through Azure DevOps and the deployment to the public repositories is performed manually using packages generated by [Create packages](#create-packages) continuous integration job. As explained in “[Create packages](#create-packages)” section, process of creating the packages is automatically triggered by completion of pull request to the `main` branch of the repository. Created packages are stored as artifacts in Azure DevOps Artifacts and are used in internal release pipelines in order to upload them to the public package managers/repositories.
 
@@ -224,6 +233,7 @@ API release process steps:
 
 ### External package managers and public repositories
 51Degrees provides APIs for a selection of programming languages and packages are available on the following public package managers:
+
 - [NuGet](https://www.nuget.org/profiles/51Degrees)
 - [Maven](https://mvnrepository.com/artifact/com.51degrees)
 - [Packagist](https://packagist.org/packages/51degrees/)
@@ -232,20 +242,28 @@ API release process steps:
 - Source code on [Github](https://github.com/51Degrees/)
 
 ## Automation
-Fully automated release process use the following flow:
+
+### Fully automated release process 
+
+The release process uses the following flow:
 1. Changes are prepared in `release|hotfix` branches.
-2. `Trigger release` job starts; or all `leaf submodules` are manually or automatically merged to `main|master`.
-3. All `leaf submodules` `release|hotfix` branches are merged to `main`.
+2. Switch `AutomatedRelease` variable in `CIAutomation` variable group to `On`.
+3. `Trigger release` job starts; or all `leaf submodules` are manually or automatically merged to `main|master`.
+   1. Since `common-ci` is a submodule of all APIs, this is normally done by having `common-ci` `release|hotfix` branch merged to `main`.
+   2. To merge `common-ci` `release|hotfix` branch to `main`, creating a pull request to `main` is enough since the pull request will be automatically completed at the end of the pull request `build-and-test` check. This is done by a task that calls a set of APIs in `Release` modules.
+4. All `leaf submodules` `release|hotfix` branches are merged to `main`.
    1. NOTE: `leaf submodules` are modules which do not have any dependencies.
-4. Completion of submodule merging triggers tag and packages deployment of the submodules. If module does not generate packages, then it will be the tag creation step.
-5. Tag and package deployment (or creation) completion triggers merging of the `release|hotfix` branches of the modules which depend on these submodules.
-6. Completion of merging `release|hotfix` branches to `main` will also trigger `deployment` of packages both internally and externally in the same way that the submodules were done.
-7. At the end of the `release` process, packages are available to be collected internally; and `deployment` to external reposition are left to be approved by `release engineer`.
+5. Completion of submodule merging triggers tag and packages deployment of the submodules. If module does not generate packages, then it will be the tag creation step.
+6. Tag and package deployment (or creation) completion triggers `submodule_trigger` pipelines of the parent APIs, which will then update submodule references, package dependencies versions and create a pull request to `main` if one does not exist.
+7. The pull request of parent APIs will then again be completed once the `build_and_test` check passes.
+8. Completion of merging `release|hotfix` branches to `main` will also trigger `deployment` of packages both internally and externally in the same way that the submodules were done.
+9. At the end of the `release` process, packages are available to be collected internally; and `deployment` to external repositories are left to be approved by `release engineer`.
+10. Switch `AutomatedRelease` variable in `CIAutomation` variable group to `Off` to prevent any accidental references update or pull request completion after this stage.
 
-The fully automated release process is controlled by a `release-config.json` file, located in the `common-ci` repository. The automated release process can also be enabled or disabled by a global variable `AutomatedRelease` as part of the Azure Devops variable group `CIAutomation`. To support automating the deployment process, powershell scripts and additional pipelines are required. These scripts are located under `common-ci` repository, and are grouped into modules. The additional pipelines are required per API, but shared templated can be reused from `common-ci`.
+The fully automated release process is controlled by a `release-config.json` file, located in the `common-ci` repository. There also exists a `release-config-template.json` which contains all settings and APIs that can be included in a `release-config.json`. The automated release process can also be enabled or disabled by a global variable `AutomatedRelease` as part of the Azure Devops variable group `CIAutomation`. To support automating the deployment process, powershell scripts and additional pipelines are required. These scripts are located under `common-ci` repository, and are grouped into modules. The additional pipelines are required per API, but shared templated can be reused from `common-ci`.
 
-Additional pipelines:
-- The `submodule trigger` pipeline is required for each API to pick up the package deployment from each of its submodules. Since a module can have multiple submodules, multiple triggers might happen at the same time. Thus, this pipeline should cancel all previous builds and only one at a single time.
+### Additional pipelines:
+- The `submodule trigger` pipeline is required for each API to pick up the package deployment from each of its submodules. Since a module can have multiple submodules, multiple triggers might happen at the same time. Thus, this pipeline should cancel all previous builds and only run one at a single time.
   - This must be triggered only by a submodule deployment that happened on the 'main' branch.
   - This pipeline, will then perform update of all submodule references and package dependencies, using the versions specified in the `release-config.json`.
 - The `pull request completion` job is required to be done at the end of each `build and test` pipeline.
@@ -253,14 +271,57 @@ Additional pipelines:
     - The `AutomatedRelease` variable has been enabled.
     - All submodule references and package dependencies have been updated.
     - The pull request has been approved and comments have been left unresolved; or approval is not required.
+- Both of the above pipelines will not proceed if a tag already exists for a release version.
+
+### Updating the Release Configuration
+
+The release configuration files must be updated to configure which repositories will be released. Each repository can be configured with the following fields:
+
+**Files to update:**
+
+- `release-config.json`
+- `cloud-release-config.json`
+
+Property|Type|Description
+-|-|-
+version|string|The target version of this repository, e.g. the version to release or the current version if a release version does not exist. Should be a valid Semantic Version e.g. `4.3.1`
+packageName|string|The name of the package that this repository contains code for. E.g. FiftyOne.Pipeline
+versionVariableName|string|The variable name used in pipelines to update dependencies.
+isLeaf|boolean|Is this a leaf of the dependency tree, i.e. does this repository have no dependencies?
+dependencies|string[]|A list of dependencies, these are the names of the repositories that this one is dependent on or contains dependencies of the contained projects.
+
+While the cloud release **is not** triggered by the automated API release, the `cloud-release-config.json` file will also need to be updated in preparation for the cloud release the following week. Only the version numbers must be updated in this file.
+
+A `release-config-template.json` file is provided which contains configurations for all the repos with a release pipeline, this should be used as a reference to modify the release config files. Only edit this file if adding a new repo configuration and updating dependencies.
+
+**Rules**
+
+There are some **rules** that a release engineer will need to pay attention to when updating the file:
+  1. `packageName`: This name is used to search for matching package reference in a package file of a target language. This is used as part of a regular expression search so regex syntax can also be used. Most of the time, the value will just be a prefix of the package name since an API usually uses unique prefix such as `FiftyOne.DeviceDetection`. However, there are APIs which use more than one prefixes such as `license-dotnet`, where `FiftyOne.License` and `FiftyOne.Resource` are used. In this specific case, the value of a `packageName` can be `FiftyOne.(License|Resource)`. Currently `DotNet` is only one which tests and supports regex `packageName`. Others language APIs have unique package `prefix` so regex is not required.
+  2. `dependencies`: When specify dependencies, make sure the definition of the dependencies are also specified, so that the release process can detect what tag to update to for submodule reference or what version to be updated for package dependencies. Failing to include the dependency definition will result in submodule references and package dependencies not being updated.
+     1. A `dependency` can be either a submodule or a package dependency.
+
+**Validation**
+
+Once the files have been updated, they can be validated by running the following PowerShell commands:
+
+- `Get-Content release-config.json | Out-String | ConvertFrom-Json` - Test JSON is valid
+- `Test-Json -Json "$(Get-Content .\release-config.json)" -SchemaFile .\release-config-schema.json` - Test the file matches the release-config schema.
+
+Steps to make changes and update the release config in common-ci repo:
+1. create new hotfix / release branch in common-ci and push to the remote - 
+   1. When determining the branch name for the common-ci hotfix or release branch, typically the version should be the same MAJOR and MINOR version of the API releases however the PATCH version does not need to match and should simply be incremented from the previous version in common-ci. See [validating branch names](#validate-the-release--hotfix-branch-names).
+2. create new feature branch for release config in common-ci and push to the remote
+3. update release config with repos, deps and versions for both
+4. commit modified release config to feature branch and create a pr from the feature branch into the release / hotfix branch.
 
-Fully automated deployment trigger procedure:
+### Fully automated deployment trigger procedure:
 1. At the start, `release engineer` will need to update the `release-config.json` to specify all release packages and their target release version. Any additional details should also be specified.
    1. NOTE: There is a `release-config-template.json` available for references.
 2. Once the `release-config.json` is ready in one of the `release|hotfix` branch of `common-ci`, either the following should trigger the release process:
    1. Complete the pull request that contains the updated `release-config.json` changes to the `main` branch. This will only work based on the assumption that the `common-ci` is specified as submodule of all release APIs.
       1. This pull request can be completed manually or automatically by the `build-and-test.yml` auto completion pull request task. The automatic completion is only enabled if the global variable `AutomatedRelease` specified in the variables group `CIAutomation` is set to `On`.
-   2. Trigger the `trigger-release` pipeline of the `common-ci`.
+   2. Trigger the `trigger-release` pipeline of the `common-ci` against the hotfix or release branch.
 
 ### Automated Release Scripts
 As briefly mentioned, the automated release process requires powershell scripts to support tasks that have been done manually. These scripts are located in the directory `scripts/modules` of the `common-ci` repository.

package/ci/common-ci/build-and-test.yml

@@ -31,7 +31,12 @@ stages:
         
         # Make sure all modules are loaded
         cd scripts\modules
-        Get-ChildItem -Directory | Foreach { Import-Module $_.Name -Force }
+        Get-ChildItem -Directory | ForEach-Object { 
+            if($(Get-ChildItem $_.FullName | Where-Object {($_ -like '*.psm1') -or ($_ -like '*.psd1')}).length -gt 0) {
+                Write-Output $_.Name
+                Import-Module $_.Name -Force 
+            }
+        }
         
         # Run all tests
         # Enable test environment so that production environment is not impacted

package/ci/common-ci/cloud-release-config.json

@@ -0,0 +1,51 @@
+{
+	"repositories": {
+		"common-ci": {
+			"version": "4.3.16",
+			"isLeaf": true
+		},
+		"pipeline-dotnet": {
+			"version": "4.3.7",
+			"packageName": "FiftyOne.Pipeline",
+			"isLeaf": true
+		},
+		"entitlement-dotnet": {
+			"version": "4.1.12",
+			"isLeaf": true
+		},
+		"location-dotnet": {
+		    "version": "4.3.6",
+			"packageName": "FiftyOne.Geolocation",
+			"isLeaf": true
+		},
+		"device-detection-dotnet": {
+			"version": "4.3.7",
+			"packageName": "FiftyOne.DeviceDetection",
+			"isLeaf": true
+		},
+		"internal-engines-dotnet": {
+			"version": "4.3.3",
+			"packageName": "FiftyOne.GeoLocation.OnPremise",
+			"isLeaf": true
+		},
+		"cloud-config": {
+			"version": "4.3.0",
+			"isLeaf": true
+		},
+		"cloud-dotnet": {
+			"version":"4.3.2",
+			"packageName": "FiftyOne.Pipeline.CloudService",
+			"isLeaf": false,
+			"dependencies": [
+				"common-ci",
+				"pipeline-dotnet",
+				"entitlement-dotnet",
+				"internal-engines-dotnet",
+				"device-detection-dotnet",
+				"location-dotnet",
+				"cloud-config"
+			]
+		}
+	},
+	"approvalRequired": false
+}

package/ci/common-ci/dotnet/shared-extract-and-publish-packages.yml

@@ -25,9 +25,5 @@ steps:
     command: push
     packagesToPush: '$(PIPELINE.WORKSPACE)/build-pipeline/drop/**/*.nupkg;!$(PIPELINE.WORKSPACE)/build-pipeline/drop/**/*.symbols.nupkg'
     nuGetFeedType: external
-    ${{ if eq(variables['System.TeamProjectId'], 'Pipeline') }}:
-      publishFeedCredentials: 'NuGet.org - Release'
-    ${{ if ne(variables['System.TeamProjectId'], 'Pipeline') }}:
-      # If not 'Pipeline' project, publish to internal instead.
-      publishVstsFeed: '${{ parameters.feed }}'
+    publishFeedCredentials: 'NuGet.org - Release'
   condition: and(succeeded(), eq('${{ parameters.nugetFeedType }}', 'external'))

package/ci/common-ci/go/shared-go-list-stage.yml

@@ -0,0 +1,64 @@
+parameters:
+- name: stageDependencies
+  type: object
+  default: []
+- name: goVersion
+  type: string
+  default: '1.17.1'
+
+stages:
+# This stage check if current branch runs on a pull request merge branch,
+# then try to complete the pull request if it is true.
+# WARNINGS: This stage should be run at the end of a pipeline, because upon
+# completing a pull request the pipeline will be canceled and no stage
+# or tasks will be run after this.
+- stage: Go_List
+  displayName: "Make module available"
+  dependsOn: ${{ parameters.stageDependencies }}
+
+  variables:
+  - group: CIAutomation # Required to access CI variables
+
+  pool:
+    vmImage: 'ubuntu-18.04'
+    
+  jobs:
+  - job: Go_List
+    
+    steps:
+    - checkout: self
+      submodules: recursive
+      persistCredentials: true
+
+    # Install go
+    - task: GoTool@0
+      displayName: 'Use go ${{ parameters.goVersion }}'
+      inputs:
+        version: '${{ parameters.goVersion }}'
+
+    # Run go list to make the module available
+    - bash: |
+        # Fetch all tags
+        git fetch --all --tags
+        if [ $? != 0 ]; then
+          echo "Failed to fetch all tags."
+          exit 1
+        fi
+
+        # Check out current branch
+        git checkout $(Build.SourceBranchName)
+        if [ $? != 0 ]; then
+          echo "Failed to checkout branch '$(Build.SourceBranchName)'."
+          exit 1
+        fi
+        
+        # Get tag version
+        export tagName="`git tag --points-at $(Build.SourceBranchName)`"
+        
+        # Get module name
+        export modName=`cat go.mod | awk '/module/{print $2}'`
+        
+        # Complete the corresponding pull request
+        GOPROXY=proxy.golang.org go list -m $modName@v$tagName
+      displayName: 'Make module available'
+      condition: and(succeeded(), eq(variables['AutomatedRelease'], 'On'))

package/ci/common-ci/java/readme.md

@@ -5,4 +5,18 @@ This API complies with the `common-ci` approach.
 We use Maven to package our Java APIs. The process of signing the result packages for Maven is different from Dotnet signing process.
 1. The signing process for Java uses `PGP ASCII Armored File` with file extension `.asc` instead of `.pfx` as in Dotnet.
 2. The process requires the `.asc` file to be imported using `gpg`.
-3. Then the result package will be signed as part of Maven `install` process using `maven-gpg-plugin`.
+3. Then the result package will be signed as part of Maven `install` process using `maven-gpg-plugin`.
+
+## Deploy External
+The deployment to external of Java Maven packages must be done in the following order:
+
+1. `pipeline-java`
+2. `device-detection-java`
+3. `location-java`
+
+Steps for each java repo:
+1. Deploy packages to Nexus staging area - automatic.
+2. Deploy from Nexus staging to Maven Central - requires approval.
+3. Deploy to GitHub - requires approval.
+
+All Java APIs share a staging area, so occasionally repositories are left in the staging area as a results of a possible cancellation or an unwanted pipeline termination, etc. This sometimes causes the deployment to staging to fail. In this case, it is the best to login to the Nexus staging area and manually drop all unwanted repositories and rerun the deployment process.

package/ci/common-ci/php/readme.md

@@ -0,0 +1,15 @@
+# PHP Specific CI/CD Approach
+This API complies with the `common-ci` approach.
+
+## Deploy External
+The deployment to external of PHP involves a stage that builds and tests on actual external package. This is not required for internal pipelines such as `build-and-test.yml` as it is acceptable to just use submodule references. However, before deploy to external, the solution is required to work with other external packages. Thus, the deployment to external will fail as some dependencies packages are left waiting for a release engineer to approve. In this case, the failed deployment will need to be rerun after their dependency packages have been deployed to external.
+
+Typically the deploy external pipelines should be completed in the following order:
+
+1. `pipeline-php-core`
+2. `pipeline-php-engines`
+3. `pipeline-php-cloudrequestengine`
+4. `device-detection-php`
+5. `location-php`
+
+`device-detection-onpremise-php` is not deployed as a package to Packagist but should be completed after `device-detection-php`

package/ci/common-ci/release-config-schema.json

@@ -0,0 +1,52 @@
+{
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
+    "type": "object",
+    "title": "Release Config",
+    "description": "Contains the release configuration for 51Degrees DevOps pipelines",
+    "properties": {
+        "repositories": {
+            "type": "object",
+            "patternProperties": {
+                "^[A-Za-z][A-Za-z0-9\\-]*$": {
+                    "type": "object",
+                    "properties": {
+                        "version": {
+                            "type": "string",
+                            "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$"
+                        },
+                        "packageName": {
+                            "type": "string"
+                        },
+                        "versionVariableName": {
+                            "type": "string"
+                        },
+                        "isLeaf": {
+                            "type": "boolean"
+                        },
+                        "dependencies": {
+                            "type": "array",
+                            "items": {
+                                "type": "string",
+                                "pattern": "^[A-Za-z][A-Za-z0-9\\-]*$"
+                            }
+                        }
+                    },
+                    "required": [
+                        "version",
+                        "isLeaf"
+                    ]
+                }
+            },
+            "required": [
+                "common-ci"
+            ]
+        },
+        "approvalRequired": {
+            "type": "boolean"
+        }
+    },
+    "required": [
+        "repositories",
+        "approvalRequired"
+    ]
+}

package/ci/common-ci/release-config-template.json

@@ -4,6 +4,10 @@
 			"version": "4.3.2",
 			"isLeaf": true
 		},
+		"device-detection-data": {
+			"version": "4.3.1",
+			"isLeaf": false
+		},
 		"common-cxx": {
 			"version": "4.3.1",
 			"isLeaf": false,
@@ -16,7 +20,8 @@
 			"isLeaf": false,
 			"dependencies": [
 				"common-ci",
-				"common-cxx"
+				"common-cxx",
+				"device-detection-data"
 			]
 		},
 		"device-detection-varnish": {
@@ -121,10 +126,29 @@
 			"dependencies": [
 				"common-ci",
 				"device-detection-cxx",
+				"caching-dotnet",
 				"common-dotnet",
 				"pipeline-dotnet"
 			]
 		},
+		"license-dotnet": {
+			"version": "4.3.0",
+			"packageName": "FiftyOne.(License|Resource)",
+			"isLeaf": false,
+			"dependencies": [
+				"common-ci"
+			]
+		},
+		"entitlement-dotnet": {
+			"version": "4.1.9",
+			"isLeaf": false,
+			"dependencies": [
+				"common-ci",
+				"common-dotnet",
+				"license-dotnet",
+				"pipeline-dotnet"
+			]
+		},
 		"internal-engines-dotnet": {
 			"version": "4.3.0",
 			"packageName": "FiftyOne.GeoLocation.OnPremise",
@@ -255,6 +279,31 @@
 				"pipeline-php-engines",
 				"pipeline-php-cloudrequestengine"
 			]
+		},
+		"pipeline-wordpress": {
+			"version": "0.9.0",
+			"packageName": "fiftyonedegrees.wordpress",
+			"isLeaf": false,
+			"dependencies": [
+				"common-ci",
+				"pipeline-php-cloudrequestengine"
+			]
+		},
+		"device-detection-go": {
+			"version": "4.3.1",
+			"isLeaf": false,
+			"dependencies": [
+				"common-ci",
+				"device-detection-cxx"
+			]
+		},
+		"device-detection-examples-go": {
+			"version": "4.3.0",
+			"isLeaf": false,
+			"dependencies": [
+				"common-ci",
+				"device-detection-go"
+			]
 		}
 	},
 	"approvalRequired": false