Skip to content

chore(release): fix typo that results in is_version_pr being falsely evaluated (#2468) - #2470

Merged
hopehadfield merged 1 commit into
redhat-developer:workspace/orchestratorfrom
hopehadfield:fix-release-orchestrator
Mar 5, 2026
Merged

chore(release): fix typo that results in is_version_pr being falsely evaluated (#2468)#2470
hopehadfield merged 1 commit into
redhat-developer:workspace/orchestratorfrom
hopehadfield:fix-release-orchestrator

Conversation

@hopehadfield

Copy link
Copy Markdown
Member

Hey, I just made a Pull Request!

Re-pushing this commit along with the workkflow fix to trigger Version Packages again.

✔️ Checklist

  • A changeset describing the change and affected packages. (more info)
  • Added or Updated documentation
  • Tests for new functionality and regression tests for bug fixes
  • Screenshots attached (for UI changes)

…evaluated (redhat-developer#2469)

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>
Co-authored-by: Hope Hadfield <hhadfiel@redhat.com>
@rhdh-qodo-merge

Copy link
Copy Markdown

Review Summary by Qodo

Add auth token and custom filters to Loki workflow logs provider

🐞 Bug fix ✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add authentication token support to Loki queries with Bearer token header
• Implement custom SSL certificate handling via rejectUnauthorized config option
• Add configurable log pipeline filters for flexible Loki query filtering
• Change default log stream selector from service_name to openshift_log_type
• Fix GitHub Actions workflow variable reference bug in version PR detection
Diagram
flowchart LR
  A["LokiProvider Config"] -->|"token, rejectUnauthorized, logPipelineFilters"| B["Enhanced LokiProvider"]
  B -->|"Bearer token header"| C["Authenticated Loki API Request"]
  B -->|"Custom Agent with SSL config"| C
  B -->|"Pipeline filters appended"| D["Flexible Log Queries"]
  E["GitHub Actions Workflow"] -->|"Fix variable reference"| F["Correct Version PR Detection"]
Loading

Grey Divider

File Changes

1. workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts ⚙️ Configuration changes +14/-0

Add authentication and pipeline filter config options

• Add required token field for Loki authentication
• Add optional rejectUnauthorized boolean for SSL certificate validation
• Add optional logPipelineFilters array for custom log filtering
• Update baseUrl documentation to clarify API endpoint appending

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts


2. workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts ✨ Enhancement +51/-5

Implement token auth and custom pipeline filters

• Add token field and getter method for authentication
• Add rejectUnauthorized field with default true value
• Add logPipelineFilters field for custom log filtering
• Implement custom Agent with SSL configuration for fetch requests
• Add Authorization Bearer token header to fetch requests
• Change default stream selector from service_name to openshift_log_type
• Append custom pipeline filters to log query string
• Import undici Agent for HTTP client configuration

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts


3. workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.test.ts 🧪 Tests +64/-6

Update tests for auth and pipeline filter features

• Add token field to all test configurations
• Add tests for getToken and getRejectUnauthorized methods
• Update default stream selector assertions from service_name to openshift_log_type
• Add test for custom pipeline filters functionality
• Remove direct fetch URL assertions, keep URL parsing assertions
• Add test case for rejectUnauthorized false configuration

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.test.ts


View more (4)
4. .github/workflows/release_workspace_version.yml 🐞 Bug fix +1/-1

Fix GitHub Actions variable reference typo

• Fix variable reference from PR_MERGED to $PR_MERGED in conditional check
• Corrects typo that caused version PR detection to always fail

.github/workflows/release_workspace_version.yml


5. workspaces/orchestrator/plugins/orchestrator-backend-module-loki/README.md 📝 Documentation +10/-1

Document new auth and pipeline filter configuration

• Add token field as required configuration parameter
• Add documentation for rejectUnauthorized option for self-signed certificates
• Add documentation for logPipelineFilters configuration with examples
• Add reference link to Loki log pipeline documentation
• Update requirements to specify both baseUrl and token as required

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/README.md


6. workspaces/orchestrator/plugins/orchestrator-backend-module-loki/package.json Dependencies +2/-1

Add undici dependency for HTTP configuration

• Add undici dependency version ^7.22.0 for HTTP client agent support

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/package.json


7. workspaces/orchestrator/.changeset/light-spiders-grin.md 📝 Documentation +7/-0

Add changeset for Loki auth and filters patch

• Create changeset for patch release of orchestrator-backend-module-loki
• Document fix for RHDHBUGS-2735 adding auth token support
• Document new custom Loki log pipeline filters feature

workspaces/orchestrator/.changeset/light-spiders-grin.md


Grey Divider

Qodo Logo

@rhdh-qodo-merge

rhdh-qodo-merge Bot commented Mar 5, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Token is now mandatory 🐞 Bug ✓ Correctness
Description
LokiProvider now calls config.getString('token') and always sends a Bearer Authorization header,
causing module initialization to throw if token is missing and breaking previously unauthenticated
Loki deployments. This is particularly risky because the changeset describes this as adding the
ability to pass a token (implying optional), yet the change is released as a patch.
Code

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[R40-46]

  private constructor(config: Config) {
    this.baseURL = config.getString('baseUrl');
+    this.token = config.getString('token');
+    // Only should be false if specified, undefined here should be true
+    this.rejectUnauthorized =
+      config.getOptionalBoolean('rejectUnauthorized') === false ? false : true;
    this.selectors = config.getOptional('logStreamSelectors') || [];
Evidence
The provider requires token at construction time (getString throws when absent) and always
includes an Authorization header. The public type and README also mark token as required, while the
changeset frames it as an added capability (not a breaking requirement).

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[40-47]
workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[136-142]
workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts[23-33]
workspaces/orchestrator/plugins/orchestrator-backend-module-loki/README.md[26-28]
workspaces/orchestrator/.changeset/light-spiders-grin.md[1-7]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`LokiProvider` currently requires `orchestrator.workflowLogProvider.loki.token` via `config.getString(&#x27;token&#x27;)`, which throws if the key is missing, breaking existing Loki installations that don’t require auth.

### Issue Context
The changeset describes this as “adds the ability to pass an auth token”, which suggests optional configuration rather than a hard requirement.

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[40-47]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[136-142]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts[23-33]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/README.md[9-33]

### Suggested approach
- Change config typing to `token?: string`.
- Read with `getOptionalString(&#x27;token&#x27;)`.
- Conditionally add `Authorization` header only when `token` is set (and consider allowing full header value vs forcing Bearer).
- Update README to reflect optional token (or explicitly document breaking change and bump major).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Agent created per request 🐞 Bug ⛯ Reliability
Description
fetchWorkflowLogsByInstance creates a new undici.Agent on every call and never closes or reuses
it, which can leak sockets/handles and degrade performance over time under repeated log queries.
This is especially likely because viewing workflow logs from the UI can trigger frequent calls.
Code

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[R127-142]

+    const customAgent = new Agent({
+      connect: {
+        // Agent configuration options, e.g., for self-signed certificates
+        rejectUnauthorized: this.rejectUnauthorized,
+      },
+    });
+
    let allResults;
    try {
-      const response = await fetch(urlToFetch);
+      const response = await fetch(urlToFetch, {
+        dispatcher: customAgent,
+        headers: {
+          Authorization: `Bearer ${this.token}`,
+          'Content-Type': 'application/json',
+        },
+      });
Evidence
The Agent is instantiated inside the request method and passed to fetch as dispatcher, but there
is no close()/destroy() in a finally block and no reuse across calls.

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[125-142]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
A new `undici.Agent` is created on every `fetchWorkflowLogsByInstance` call and never closed/reused, risking resource leaks (sockets/handles) and performance degradation.

### Issue Context
`fetchWorkflowLogsByInstance` can be called frequently (e.g., every time a user views logs or refreshes).

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[124-142]

### Suggested approach
- Prefer: create `private readonly dispatcher: Agent` in the constructor (or lazily on first use) and reuse it.
- Alternative: wrap the fetch in `try/finally` and call `customAgent.close()` (or appropriate teardown) in `finally`.
- Consider only using a custom dispatcher when `baseUrl` is https or when `rejectUnauthorized` is explicitly configured.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Selector default mismatch 🐞 Bug ✓ Correctness
Description
The code now defaults missing selector labels to openshift_log_type, but an existing unit test
still expects service_name when a selector entry omits label. This inconsistency will cause the
test to fail (and indicates unclear intended behavior for partially specified selectors).
Code

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[R100-101]

      this.selectors.forEach(
        (
Evidence
LokiProvider uses openshift_log_type when entry.label is falsy, while the unit test builds an
expected URL/query assuming the fallback label remains service_name for an entry that only
provides value. These cannot both be correct, so CI will fail unless code or test is updated.

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[96-109]
workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.test.ts[249-297]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Unit tests and implementation disagree about the fallback label when a logStreamSelectors entry omits `label`. Implementation uses `openshift_log_type`, while the test expects `service_name`.

### Issue Context
This is specifically about partially-specified selector entries (e.g., `{ value: &#x27;=~&quot;.+&quot;&#x27; }`).

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[100-108]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.test.ts[249-297]

### Suggested approach
- Choose one behavior:
 - **Option A (OpenShift-first):** keep `openshift_log_type` fallback and update the test’s expected query accordingly.
 - **Option B (backward-compatible/generic):** restore fallback to `service_name` and update docs/comments if needed.
- Add/adjust a test to lock in the chosen behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Hardcoded OpenShift selector 🐞 Bug ✓ Correctness
Description
When no logStreamSelectors are configured, the provider hardcodes
{openshift_log_type="application"} as the stream selector; this may return no logs in
non-OpenShift Loki environments and is not configurable. The code comment itself notes this might
need to be configurable, suggesting this should be exposed via configuration or documented as
OpenShift-only behavior.
Code

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[R91-99]

+    // The log stream selector part of the query here is defaulting to openshift_log_type=application
+    // This is the value used for Openshift Logging
    // This might need to be configurable, based on https://grafana.com/docs/loki/latest/query/log_queries/#log-stream-selector
    // Log pipeline part looks for the workflow instance id in those logs
    // Create the streamSelector
    let streamSelector: string = '';
    if (this.selectors.length < 1) {
-      streamSelector = 'service_name=~".+"';
+      streamSelector = 'openshift_log_type="application"';
    } else {
Evidence
The default selector is hardcoded in code, but the module’s public config surface only offers an
optional logStreamSelectors array and does not provide a way to set the fallback default. This can
cause silent “no logs” behavior if the label doesn’t exist in a given Loki deployment.

workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[91-99]
workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts[23-48]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The Loki query’s default stream selector is hardcoded to an OpenShift-specific label/value when `logStreamSelectors` is empty, which can lead to empty results in other environments.

### Issue Context
The current config surface does not provide a way to override the fallback default (only to provide explicit selectors).

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[88-110]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts[20-48]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/README.md[9-33]

### Suggested approach
- Add a config option for the fallback default selector (string or label/value pair).
- Or keep the previous generic default and recommend OpenShift users set `logStreamSelectors` explicitly.
- Update README to document the default behavior clearly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines 40 to 46
private constructor(config: Config) {
this.baseURL = config.getString('baseUrl');
this.token = config.getString('token');
// Only should be false if specified, undefined here should be true
this.rejectUnauthorized =
config.getOptionalBoolean('rejectUnauthorized') === false ? false : true;
this.selectors = config.getOptional('logStreamSelectors') || [];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Token is now mandatory 🐞 Bug ✓ Correctness

LokiProvider now calls config.getString('token') and always sends a Bearer Authorization header,
causing module initialization to throw if token is missing and breaking previously unauthenticated
Loki deployments. This is particularly risky because the changeset describes this as adding the
ability to pass a token (implying optional), yet the change is released as a patch.
Agent Prompt
### Issue description
`LokiProvider` currently requires `orchestrator.workflowLogProvider.loki.token` via `config.getString('token')`, which throws if the key is missing, breaking existing Loki installations that don’t require auth.

### Issue Context
The changeset describes this as “adds the ability to pass an auth token”, which suggests optional configuration rather than a hard requirement.

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[40-47]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[136-142]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/config.d.ts[23-33]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/README.md[9-33]

### Suggested approach
- Change config typing to `token?: string`.
- Read with `getOptionalString('token')`.
- Conditionally add `Authorization` header only when `token` is set (and consider allowing full header value vs forcing Bearer).
- Update README to reflect optional token (or explicitly document breaking change and bump major).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +127 to +142
const customAgent = new Agent({
connect: {
// Agent configuration options, e.g., for self-signed certificates
rejectUnauthorized: this.rejectUnauthorized,
},
});

let allResults;
try {
const response = await fetch(urlToFetch);
const response = await fetch(urlToFetch, {
dispatcher: customAgent,
headers: {
Authorization: `Bearer ${this.token}`,
'Content-Type': 'application/json',
},
});

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Agent created per request 🐞 Bug ⛯ Reliability

fetchWorkflowLogsByInstance creates a new undici.Agent on every call and never closes or reuses
it, which can leak sockets/handles and degrade performance over time under repeated log queries.
This is especially likely because viewing workflow logs from the UI can trigger frequent calls.
Agent Prompt
### Issue description
A new `undici.Agent` is created on every `fetchWorkflowLogsByInstance` call and never closed/reused, risking resource leaks (sockets/handles) and performance degradation.

### Issue Context
`fetchWorkflowLogsByInstance` can be called frequently (e.g., every time a user views logs or refreshes).

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[124-142]

### Suggested approach
- Prefer: create `private readonly dispatcher: Agent` in the constructor (or lazily on first use) and reuse it.
- Alternative: wrap the fetch in `try/finally` and call `customAgent.close()` (or appropriate teardown) in `finally`.
- Consider only using a custom dispatcher when `baseUrl` is https or when `rejectUnauthorized` is explicitly configured.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines 100 to 101
this.selectors.forEach(
(

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. Selector default mismatch 🐞 Bug ✓ Correctness

The code now defaults missing selector labels to openshift_log_type, but an existing unit test
still expects service_name when a selector entry omits label. This inconsistency will cause the
test to fail (and indicates unclear intended behavior for partially specified selectors).
Agent Prompt
### Issue description
Unit tests and implementation disagree about the fallback label when a logStreamSelectors entry omits `label`. Implementation uses `openshift_log_type`, while the test expects `service_name`.

### Issue Context
This is specifically about partially-specified selector entries (e.g., `{ value: '=~".+"' }`).

### Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.ts[100-108]
- workspaces/orchestrator/plugins/orchestrator-backend-module-loki/src/workflowLogsProviders/LokiProvider.test.ts[249-297]

### Suggested approach
- Choose one behavior:
  - **Option A (OpenShift-first):** keep `openshift_log_type` fallback and update the test’s expected query accordingly.
  - **Option B (backward-compatible/generic):** restore fallback to `service_name` and update docs/comments if needed.
- Add/adjust a test to lock in the chosen behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@hopehadfield
hopehadfield force-pushed the fix-release-orchestrator branch from 300b13c to ccd1b3c Compare March 5, 2026 17:09
@sonarqubecloud

sonarqubecloud Bot commented Mar 5, 2026

Copy link
Copy Markdown

@hopehadfield hopehadfield changed the title Orchestrator: bug fix for logging for workflows feature (#2431) chore(release): fix typo that results in is_version_pr being falsely evaluated (#2468) Mar 5, 2026
@hopehadfield
hopehadfield merged commit 5a2b6ac into redhat-developer:workspace/orchestrator Mar 5, 2026
2 checks passed
@hopehadfield
hopehadfield deleted the fix-release-orchestrator branch April 8, 2026 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants