[DO NOT MERGE] Fix CI Key OrgID

[tbuchaillot]

Description

Related Issue

**This PR shouldn't be merged - the underlying code problem should be solved separately **

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• I ensured that the documentation is up to date
• I explained why this PR updates go.mod in detail with reasoning why it's required
• I would like a code coverage CI quality gate exception and have explained why

[probelabs]

This pull request updates CI test configurations by adding an org_id to a test API key. This ensures the test data aligns with the system's multi-tenancy requirements.

Files Changed Analysis

• ci/tests/specs/config/portmanconfig.json: An org_id is added to the Portman test configuration for a specific key.
• ci/tests/specs/testdata/populate_gateway_test_data.yaml: The corresponding test data for the gateway is updated with the same org_id.
• main.go: A blank line is removed. This is a non-functional change, likely intended to ensure the CI pipeline is triggered by the commit.

Architecture & Impact Assessment

• What this PR accomplishes: It fixes a CI test failure by ensuring that the test API key includes an org_id, which is a required attribute for resource scoping in the gateway.
• Key technical changes introduced: The primary change is the hardcoding of an org_id in two separate test configuration files.
• Affected system components: The changes are strictly limited to the CI test suite. There is no impact on the production gateway's logic or architecture.

Scope Discovery & Context Expansion

The org_id is a fundamental concept in Tyk for enabling multi-tenancy, scoping resources like API definitions, policies, and session states (keys) to a specific organization. This PR's changes are confined to the test environment but reflect a core architectural principle. The addition of the org_id to test data suggests that recent changes in the gateway have enforced this association more strictly, causing tests with legacy data to fail.

Metadata

• Review Effort: 1 / 5
• Primary Label: chore

---

Powered by Visor from Probelabs

Last updated: 2026-01-30T13:03:23.576Z | Triggered by: pr_updated | Commit: 4df5a25

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

✅ Security Check Passed

No security issues found – changes LGTM.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	ci/tests/specs/config/portmanconfig.json:298	The organization ID `664a14650619d40001f1f00f` is hardcoded and duplicated in `ci/tests/specs/testdata/populate_gateway_test_data.yaml` (line 139). Using hardcoded 'magic' values across multiple test configuration files makes the test suite brittle and difficult to maintain. If this ID needs to be updated, it must be changed in multiple places, increasing the risk of inconsistency. 💡 Suggestion Centralize test data constants, like this organization ID, into a single source of truth. For example, define it as a variable in a shared configuration file or an environment variable that both test suites can read from. This will improve maintainability by ensuring the value is defined in only one place.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (2)

Severity	Location	Issue
🟠 Error	ci/tests/specs/config/portmanconfig.json:294-298	The hardcoded `org_id` "664a14650619d40001f1f00f" is a magic number. Using unexplained, hardcoded values in test configurations makes them brittle and difficult to maintain. If this ID needs to be updated, it must be changed in multiple places, risking inconsistencies. 💡 Suggestion Define this ID as a variable in a shared configuration or as an environment variable. The test setup can then inject this variable into both `portmanconfig.json` and `populate_gateway_test_data.yaml`, ensuring a single source of truth and improving maintainability.
🟠 Error	ci/tests/specs/testdata/populate_gateway_test_data.yaml:139	The hardcoded `org_id` "664a14650619d40001f1f00f" is a magic number and is duplicated from another test configuration file. This violates the DRY (Don't Repeat Yourself) principle and makes the test suite harder to maintain. 💡 Suggestion This value should be sourced from a single, shared location, such as an environment variable or a central configuration file, and referenced here. This avoids duplication and ensures consistency across the test data.

---

Powered by Visor from Probelabs

Last updated: 2026-01-30T13:03:28.308Z | Triggered by: pr_updated | Commit: 4df5a25

💡 TIP: You can chat with Visor using /visor ask <your question>

[github-actions]

API Changes

no api changes detected

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🚨 Jira Linter Failed

Commit: 4df5a25
Failed at: 2026-01-30 13:54:46 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate branch and PR title rules: branch name 'ci/test' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.