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

[kofoworola]

Replaces setup-go + go install with a single docker run against the image published to ECR.

#162 carried this change but merged into its stacked base branch instead of main, so main never got it.

main and production are broken right now. #155 bumped go.mod to go 1.26 and left action.yaml pinning setup-go to 1.24.7. setup-go sets GOTOOLCHAIN=local, so every consumer on @production fails with:

go: go.mod requires go >= 1.26 (running go 1.24.7; GOTOOLCHAIN=local)

File	Change
jira-linter/action.yaml	Two build steps become one docker run, plus two ECR login steps
.github/workflows/ci-test.yml	Go 1.26, matching go.mod
.github/workflows/jira-lint.yaml	id-token: write
docs/workflows/jira-lint.md	Caller permission requirement

Everything after the linter step is unchanged. The action stays composite because a private ECR image rules out using: docker.

Verified against the live Jira API: role assumption, ECR login, image pull, and container run all succeeded in 18s.

Before promoting production, consumers need id-token: write on the calling job or they break on the ECR login. tyk-operator-internal#252 does this; tyk still needs it.

🤖 Generated with Claude Code

[github-actions]

zizmor findings

Severity	Count
High	90
Medium	89
Low	2
Info	11

Full details are in the workflow run.

[probelabs]

This PR refactors the jira-linter GitHub Action to run from a pre-built Docker image hosted in a private Amazon ECR registry, rather than being built from source during workflow execution. This change fixes a critical build failure on the main branch caused by a Go version mismatch between the action's configuration and the repository's go.mod file.

Files Changed Analysis

• jira-linter/action.yaml: The core execution logic is modified. The steps for setting up Go and building the linter are replaced with steps to authenticate with AWS ECR using OIDC, log in, and then run the linter via a docker run command.
• .github/workflows/jira-lint.yaml: Adds the id-token: write permission, which is now required for the action to authenticate with AWS and pull the container image.
• .github/workflows/ci-test.yml: The Go version is updated to 1.26 to align with the project's go.mod, resolving CI failures.
• docs/workflows/jira-lint.md: Documentation is updated to inform users of the new id-token: write permission requirement.

Architecture & Impact Assessment

• Accomplishment: This PR resolves a build-breaking issue in main and improves the reliability and consistency of the jira-linter action by encapsulating its environment in a Docker container.
• Key Technical Changes: The action's execution model shifts from a source-build composite action to a container-based one. It introduces a dependency on AWS ECR and uses OIDC for secure, passwordless authentication between GitHub Actions and AWS.
• Affected Components: The primary impact is on the jira-linter action and all workflows that consume it. All consuming repositories must now add permissions: { id-token: write } to the job that calls this action to avoid breaking their CI checks.

The new authentication and execution flow is as follows:

sequenceDiagram
    participant Runner as GitHub Runner
    participant OIDC as GitHub OIDC Provider
    participant AWS_STS as AWS STS
    participant ECR as Amazon ECR
    participant Container as Jira Linter Container

    Runner->>OIDC: Request JWT (id-token)
    OIDC-->>Runner: Provide JWT
    Runner->>AWS_STS: AssumeRoleWithWebIdentity(Role: ecr_rw_tyk, JWT)
    AWS_STS-->>Runner: Provide Temporary AWS Credentials
    Runner->>ECR: Login with AWS Credentials
    ECR-->>Runner: Login Succeeded
    Runner->>ECR: Pull jira-linter image
    ECR-->>Runner: Provide image
    Runner->>Container: docker run jira-linter:latest
    Container-->>Runner: Linter output (stdout/stderr)

Loading

Scope Discovery & Context Expansion

The impact of this change extends beyond this repository to all projects that use the jira-linter action (e.g., via @production tag). The PR description correctly notes that promoting this change to production without updating consumer repositories will cause widespread CI failures. A coordinated effort will be needed to update all repositories that use this action, such as tyk and tyk-operator-internal, to include the required id-token: write permission.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-09-17T12:27:00.165Z | Triggered by: pr_opened | Commit: dac93d7

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

[probelabs]

Security Issues (3)

Severity	Location	Issue
🟡 Warning	jira-linter/action.yaml:17	The GitHub actions `aws-actions/configure-aws-credentials` and `aws-actions/amazon-ecr-login` are pinned to v1, which is outdated. The latest stable versions are v4 and v2, respectively. Using older versions may expose the workflow to security vulnerabilities that have been patched in newer releases and may lack important features or bug fixes. 💡 Suggestion Update the actions to their latest major stable versions to benefit from security patches and new features. Pin to a specific version hash to ensure immutability. - name: Configure AWS credentials for use uses: aws-actions/configure-aws-credentials@v4 # or a specific hash with: role-to-assume: arn:aws:iam::754489498669:role/ecr_rw_tyk role-session-name: cipush aws-region: eu-central-1 - name: Login to Amazon ECR id: login-ecr uses: aws-actions/amazon-ecr-login@v2 # or a specific hash
🟡 Warning	jira-linter/action.yaml:19	The assumed IAM role `ecr_rw_tyk` suggests read-write permissions. However, the action only needs to pull an image from ECR, which requires read-only access. Granting excessive permissions violates the principle of least privilege and increases the potential impact of a compromised runner. 💡 Suggestion Create and use a dedicated IAM role with the minimum required read-only permissions for pulling an image from ECR. This typically includes `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, and `ecr:BatchGetImage`.
🟡 Warning	jira-linter/action.yaml:38	The action pulls the Docker image using the mutable `:latest` tag. This can lead to unpredictable behavior, as the image behind the tag can change without any modification to the workflow file. It makes it difficult to track which version of the linter was executed and complicates rollbacks. 💡 Suggestion Replace the `:latest` tag with an immutable identifier, such as a specific version tag (e.g., `v1.2.3`) or the image digest (SHA). This ensures that workflow runs are deterministic and reproducible.

Architecture Issues (2)

Severity	Location	Issue
🟠 Error	jira-linter/action.yaml:41	The action pulls the Docker image using the `:latest` tag. This introduces non-determinism into the CI pipeline, as the underlying image can change at any time, potentially causing unexpected failures or behavior changes. Builds are no longer reproducible, and debugging becomes significantly harder when the tool version is not pinned. 💡 Suggestion Replace the `:latest` tag with an immutable tag, such as a semantic version (e.g., `v1.2.3`) or the Git commit SHA. The image publishing pipeline should be updated to push such tags, and this action should be updated to reference a specific, stable version of the linter image.
🟡 Warning	jira-linter/action.yaml:19-41	The AWS role ARN, region, and the full ECR image URI are hard-coded in the action's definition. This tightly couples the action to a specific AWS environment, limiting its reusability and making it difficult to test or adapt for other environments (e.g., different AWS accounts or regions) without modifying the action's source code. 💡 Suggestion To improve flexibility and reusability, convert these hard-coded values into action inputs with default values. This would allow consuming workflows to override them if necessary while preserving the current behavior for existing users. For example, create inputs for `aws-role-to-assume`, `aws-region`, and `linter-image-uri`.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	jira-linter/action.yaml:43	The Docker image is referenced using the ':latest' tag. This is a mutable tag, which can cause unpredictable behavior if the underlying image is updated. From a performance perspective, it forces the container runtime to check with the remote registry on each run to validate the image digest, adding network latency. Using an immutable tag (like a git SHA or a semantic version) improves reliability and allows for more effective local caching, potentially speeding up runs. 💡 Suggestion Replace the ':latest' tag with an immutable tag, such as a specific version or a git commit SHA. This will require the process that publishes the Docker image to use immutable tags.

---

Powered by Visor from Probelabs

Last updated: 2026-09-17T12:26:57.883Z | Triggered by: pr_opened | Commit: dac93d7

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