TT-16030: run the jira-linter from the published image

[kofoworola]

Stacked on #155. The base branch is feat/TT-16030/jira-linter-docker, so this diff shows only the consumer switch. Merge #155 first; GitHub then retargets this PR to main automatically.

What this does

TT-16030

Stops the action installing a Go toolchain and compiling the linter on every pull request run. It runs the published image instead.

Set up Go and Build Jira Linter are replaced by one docker run. Everything after the linter step is untouched.

Ticket Details

TT-16030

Status	In Code Review
Summary	Optimize the jira-linter action to enhance its efficiency

Generated at: 2026-09-16 12:39:23

Before VS After

[probelabs]

This pull request transitions the jira-linter GitHub Action from being compiled from source on each run to using a pre-published Docker image from a private AWS ECR registry. The primary goal is to enhance CI efficiency by removing the Go toolchain setup and build steps. This change introduces a new requirement for consuming workflows to grant id-token: write permissions for OIDC authentication with AWS.

Files Changed Analysis

• jira-linter/action.yaml: The core logic is updated. Steps for setting up Go and building the linter are replaced with steps to assume an AWS IAM role, log in to ECR, and execute the linter via docker run.
• .github/workflows/jira-lint.yaml: The reusable workflow is modified to request id-token: write permissions. This is a breaking change for all consumers, who must now grant this permission in their calling workflows.
• docs/workflows/jira-lint.md: Documentation is updated to explain the new id-token: write permission requirement, providing context and a usage example.
• .github/workflows/ci-test.yml: The Go version used in the CI test workflow is updated.

Architecture & Impact Assessment

• What this PR accomplishes: It optimizes the jira-linter action by switching from an on-demand source build to a pre-built Docker image, resulting in faster CI jobs.
• Key technical changes introduced: The execution model shifts from building from source to running a container. This introduces a dependency on a private AWS ECR registry and requires OIDC authentication for image pulls.
• Affected system components: This change impacts all downstream repositories using the .github/workflows/jira-lint.yaml reusable workflow. They must update their CI configurations to add id-token: write permissions to avoid workflow failures.

Execution Flow Comparison

Before (Build from Source):

graph TD
    A[Start Workflow] --> B[Set up Go Toolchain];
    B --> C[Build Linter from Source];
    C --> D[Run Linter Binary];
    D --> E[End];

Loading

After (Run from Image):

graph TD
    A[Start Workflow] --> B[Assume AWS Role via OIDC];
    B --> C[Login to ECR];
    C --> D[Pull & Run Linter Docker Image];
    D --> E[End];

Loading

Scope Discovery & Context Expansion

• This PR is part of a stacked series, building on PR TT-18249: build and publish the jira-linter image to ECR #155. This diff specifically focuses on the consumer-facing changes required to use the new Docker-based action.
• The most significant impact is external. All repositories that use .github/workflows/jira-lint.yaml must be identified and updated to grant the required permissions, making this a coordinated breaking change across multiple projects.

Metadata

• Review Effort: 3 / 5
• Primary Label: enhancement

---

Powered by Visor from Probelabs

Last updated: 2026-09-16T12:42:55.747Z | Triggered by: pr_updated | Commit: f355dcb

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

[github-actions]

zizmor findings

Severity	Count
High	90
Medium	89
Low	2
Info	11

Full details are in the workflow run.

[probelabs]

Security Issues (3)

Severity	Location	Issue
🔴 Critical	jira-linter/action.yaml:21	The IAM role `arn:aws:iam::754489498669:role/ecr_rw_tyk` appears to grant read-write permissions, which is overly permissive for pulling a Docker image. This violates the principle of least privilege and increases the risk of a supply chain attack if the workflow's credentials are compromised, as an attacker could push malicious images to the ECR repository. 💡 Suggestion Create and use a new IAM role with read-only permissions scoped to the `jira-linter` ECR repository. The policy should only grant the minimum permissions required to pull an image, such as `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, and `ecr:BatchGetImage`.
🟠 Error	jira-linter/action.yaml:38	The Docker image is referenced using the `:latest` tag, which makes the build non-deterministic and vulnerable to supply chain attacks. If the `latest` tag is ever overwritten with a malicious or broken image, it will be automatically pulled by this workflow. 💡 Suggestion Pin the Docker image to a specific immutable digest (`@sha256:...`) instead of a mutable tag like `:latest`. This ensures that the exact same version of the linter is used in every workflow run, improving security and reproducibility.
🟡 Warning	jira-linter/action.yaml:19-25	The workflow uses outdated major versions of `aws-actions/configure-aws-credentials` (v1) and `aws-actions/amazon-ecr-login` (v1). The latest available versions are v4 and v2, respectively. Using outdated actions can expose the workflow to security vulnerabilities that have been fixed in newer releases. 💡 Suggestion Update the actions to their latest major versions to benefit from security patches and improvements. Use `aws-actions/configure-aws-credentials@v4` and `aws-actions/amazon-ecr-login@v2`, preferably pinning to a specific commit SHA for maximum security.

Architecture Issues (2)

Severity	Location	Issue
🟠 Error	jira-linter/action.yaml:39	The action uses the `latest` tag to pull the `jira-linter` Docker image. This practice can lead to non-reproducible and unstable CI runs, as the image referenced by `latest` can change unexpectedly, potentially introducing breaking changes or bugs without any code changes in this repository. 💡 Suggestion Pin the Docker image to a specific, immutable version tag (e.g., a semantic version like `v1.2.3` or a commit SHA) instead of `latest`. This ensures that the action's behavior is consistent and predictable. Consider making the image tag a configurable input to allow for controlled upgrades.
🟡 Warning	jira-linter/action.yaml:18-20	The action is tightly coupled to a specific AWS environment by hard-coding the IAM role ARN (`arn:aws:iam::754489498669:role/ecr_rw_tyk`) and AWS region (`eu-central-1`). This limits its reusability and makes it brittle to infrastructure changes. 💡 Suggestion Parameterize the AWS role and region by defining them as inputs with default values. This allows consumers to override them if needed, making the action more flexible and portable for use in different environments.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	jira-linter/action.yaml:39-41	The Docker image is pulled using the `:latest` tag, which is inefficient for caching. GitHub runners may not effectively cache the image between workflow runs, as they must always check if the `latest` tag points to a new image digest. This can lead to unnecessary image downloads and slower execution times, partially negating the performance benefit of switching to a pre-built image. 💡 Suggestion Replace the `:latest` tag with an immutable tag, such as a specific version (e.g., `v1.0.0`) or the Git commit SHA. Using immutable tags allows Docker and the GitHub runner environment to reliably cache the image, ensuring that it is only pulled when the tag actually changes. This will result in faster startup times for subsequent workflow runs.

Quality Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-lint-self.yml:18	The job name `lint without container` is misleading. The context of the pull request indicates a switch to a container-based execution model, and the job's permissions (`id-token: write`) are configured to pull an image from ECR. The name should be updated to accurately reflect the job's purpose. 💡 Suggestion Rename the job to be more descriptive of its function, such as `Self-lint` or `Lint PR`.
🟡 Warning	jira-linter/action.yaml:18	This pull request's stated goal is to switch consumers to a Docker-based action. The change updating the Go version is unrelated to this purpose. Furthermore, the PR description implies that the Go build steps are being removed in the base branch of this PR stack, which makes modifying the Go version here confusing. Pull requests should ideally focus on a single concern. 💡 Suggestion Remove the Go version change from this pull request to keep it focused on the consumer-side changes. If the Go version needs updating, that change belongs in the base PR or a separate, dedicated PR.

---

Powered by Visor from Probelabs

Last updated: 2026-09-16T12:42:29.449Z | Triggered by: pr_updated | Commit: f355dcb

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