Skip to content

ci(release): rename codiumai/pr-agent to pragent/pr-agent#2360

Merged
naorpeled merged 1 commit intomainfrom
ci/rename-registry
May 2, 2026
Merged

ci(release): rename codiumai/pr-agent to pragent/pr-agent#2360
naorpeled merged 1 commit intomainfrom
ci/rename-registry

Conversation

@naorpeled
Copy link
Copy Markdown
Member

Summary

Renames the Docker image namespace from codiumai/pr-agent to pragent/pr-agent across docs, CI workflows, and the GitHub Action's base image.

This PR is stacked on top of #2359 (release workflow) — the base is set to ci/release-workflow so the diff shows only the rename. Once #2359 merges to main, retarget this PR's base to main (GitHub will offer this automatically) and merge.

Why split from #2359

#2359 should land first publishing under the existing codiumai/pr-agent namespace so we can validate the release flow against the registry users currently depend on. Once verified, this PR migrates the namespace.

Changed in this PR

  • .github/workflows/publish.yml — registry tags switch to pragent/pr-agent
  • Dockerfile.github_action_dockerhub — base image flips to pragent/pr-agent:github_action (so the GitHub Action stays in sync after the migration)
  • .github/workflows/build-and-test.yaml, code_coverage.yaml, e2e_tests.yaml — local :test tag uses the new namespace for consistency
  • SECURITY.md, docs/docs/installation/{azure,bitbucket,gitea,github,gitlab,locally}.md, docs/docs/tools/help_docs.md — user-facing docker pull / image: references

Intentionally NOT changed

  • RELEASE_NOTES.md — historical record of past publishes under the old namespace
  • pr_agent/git_providers/{bitbucket_provider,gitlab_provider}.py — the codiumai/pr-agent strings in those files are git-URL examples in code comments (bitbucket.org/codiumai/pr-agent.git, gitlab.com/codiumai/pr-agent.git), not Docker images
  • tests/e2e_tests/test_gitlab_webhook.py'codiumai/pr-agent-tests' is a separate fixtures repo

Test plan

  • Wait for ci(release): add release-drafter and automated publish workflow #2359 to merge and the first release run to validate the publish flow.
  • Rebase this PR onto main (or let GitHub auto-retarget once base merges).
  • Cut a release after merging this PR and confirm Docker Hub now serves pragent/pr-agent:* and that action.yaml (via Dockerfile.github_action_dockerhub) pulls cleanly.
  • Update Docker Hub access (PAT/team perms) so the DOCKERHUB_TOKEN secret has write access to the pragent namespace before merging.

Copilot AI review requested due to automatic review settings May 2, 2026 19:10
@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Rename Docker image namespace from codiumai/pr-agent to pragent/pr-agent

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Rename Docker image namespace from codiumai/pr-agent to pragent/pr-agent
• Update CI workflows to use new registry namespace for consistency
• Update installation and security documentation with new image references
• Update GitHub Action base image to pull from new namespace
Diagram
flowchart LR
  old["codiumai/pr-agent"]
  new["pragent/pr-agent"]
  workflows["CI Workflows"]
  docs["Documentation"]
  action["GitHub Action"]
  
  old -- "rename to" --> new
  new --> workflows
  new --> docs
  new --> action
Loading

Grey Divider

File Changes

1. .github/workflows/publish.yml ⚙️ Configuration changes +3/-3

Update publish workflow registry namespace

.github/workflows/publish.yml


2. .github/workflows/build-and-test.yaml ⚙️ Configuration changes +2/-2

Update test workflow image references

.github/workflows/build-and-test.yaml


3. .github/workflows/code_coverage.yaml ⚙️ Configuration changes +2/-2

Update code coverage workflow image tags

.github/workflows/code_coverage.yaml


View more (10)
4. .github/workflows/e2e_tests.yaml ⚙️ Configuration changes +4/-4

Update e2e test workflow image references

.github/workflows/e2e_tests.yaml


5. Dockerfile.github_action_dockerhub ⚙️ Configuration changes +1/-1

Update GitHub Action base image namespace

Dockerfile.github_action_dockerhub


6. SECURITY.md 📝 Documentation +2/-2

Update security documentation image references

SECURITY.md


7. docs/docs/installation/azure.md 📝 Documentation +1/-1

Update Azure installation guide image reference

docs/docs/installation/azure.md


8. docs/docs/installation/bitbucket.md 📝 Documentation +3/-3

Update Bitbucket installation guide image references

docs/docs/installation/bitbucket.md


9. docs/docs/installation/gitea.md 📝 Documentation +1/-1

Update Gitea installation guide image reference

docs/docs/installation/gitea.md


10. docs/docs/installation/github.md 📝 Documentation +8/-8

Update GitHub installation guide image references

docs/docs/installation/github.md


11. docs/docs/installation/gitlab.md 📝 Documentation +5/-5

Update GitLab installation guide image references

docs/docs/installation/gitlab.md


12. docs/docs/installation/locally.md 📝 Documentation +5/-5

Update local installation guide image references

docs/docs/installation/locally.md


13. docs/docs/tools/help_docs.md 📝 Documentation +1/-1

Update help documentation image reference

docs/docs/tools/help_docs.md


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

qodo-free-for-open-source-projects Bot commented May 2, 2026

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (3)

Grey Divider


Action required

1. E2E repo path mismatch 🐞 Bug ≡ Correctness
Description
tests/e2e_tests/test_gitlab_webhook.py now uses the GitLab project path pragent/pr-agent-tests,
but other E2E tests still reference codiumai/Codium-ai for the same fixtures repo, so the GitLab
E2E is likely to fail at gl.projects.get(repo_url) if the fixtures repo wasn’t migrated.
Code

tests/e2e_tests/test_gitlab_webhook.py[R29-30]

+    repo_url = 'pragent/pr-agent-tests'
   project = gl.projects.get(repo_url)
Evidence
The GitLab E2E test was switched to pragent/pr-agent-tests, but other E2E tests in this repo still
target Codium-ai/pr-agent-tests (GitHub) and codiumai (Bitbucket/Gitea), indicating the fixture
repository location is not consistently updated across the test suite.

tests/e2e_tests/test_gitlab_webhook.py[24-31]
tests/e2e_tests/test_github_app.py[23-36]
tests/e2e_tests/test_bitbucket_app.py[27-32]
tests/e2e_tests/test_gitea_app.py[22-26]

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 GitLab E2E test hard-codes a different `pr-agent-tests` repo path (`pragent/pr-agent-tests`) than the rest of the E2E tests (`codiumai` / `Codium-ai`), which can break CI by failing to resolve the project.
### Issue Context
This PR is a Docker image namespace migration; the E2E fixtures repo namespace/org may not have moved.
### Fix Focus Areas
- tests/e2e_tests/test_gitlab_webhook.py[24-31]
### What to change
- Pick the canonical fixture repo location for `pr-agent-tests` and make the GitLab E2E test match it.
- (Optional but safer) centralize the fixture repo owner/path in one place (e.g., settings/env var) so future namespace changes don’t require updating multiple tests.

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


2. Tag targets unbumped commit 🐞 Bug ≡ Correctness
Description
In workflow_dispatch publishes, if the version-bump commit cannot be pushed (non-fast-forward), the
workflow still creates a tag/release targeting the pre-bump commit SHA. This can produce a release
tag whose tree (pyproject.toml version) does not match the version used to build/publish PyPI and
Docker artifacts.
Code

.github/workflows/publish.yml[R224-252]

+          if git diff --quiet pyproject.toml; then
+            echo "pyproject.toml already at $VERSION on $PUBLISHED_SHA; nothing to commit."
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          git add pyproject.toml
+          git commit -m "chore(release): bump version to $VERSION [skip ci]"
+          if git push origin "HEAD:refs/heads/main"; then
+            echo "bumped=true" >> "$GITHUB_OUTPUT"
+            echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          else
+            echo "::warning::main has moved past the published commit ($PUBLISHED_SHA); skipping bump push and tag-move so the tag continues to point at built artifacts. Bump pyproject.toml on main manually:  git checkout main && python scripts/set_pyproject_version.py $VERSION && git commit -am 'chore(release): bump version to $VERSION' && git push"
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Create tag and GitHub Release (workflow_dispatch only)
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          GH_TOKEN: ${{ secrets.RELEASE_TOKEN || secrets.GITHUB_TOKEN }}
+          TAG: ${{ needs.prepare.outputs.tag }}
+          SHA: ${{ steps.commit.outputs.sha }}
+        run: |
+          if gh release view "$TAG" >/dev/null 2>&1; then
+            echo "Release $TAG already exists; not recreating."
+          else
+            gh release create "$TAG" --target "$SHA" --title "$TAG" --generate-notes
+          fi
Evidence
The commit step sets the output SHA back to the original published SHA when the push fails, but the
subsequent workflow_dispatch release creation unconditionally uses that SHA as the tag target,
despite the workflow’s own stated invariant about tags resolving to published trees.

.github/workflows/publish.yml[194-205]
.github/workflows/publish.yml[218-239]
.github/workflows/publish.yml[241-252]

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

## Issue description
On `workflow_dispatch`, the workflow can create a tag/Release pointing to `PUBLISHED_SHA` even when the bump commit couldn’t be pushed to `main`. That tag then references a commit whose `pyproject.toml` version may not match the version used to build/publish artifacts.
### Issue Context
In the `Commit & push bump` step, when `git push` fails, the step writes `sha=$PUBLISHED_SHA` to `$GITHUB_OUTPUT`. The subsequent `Create tag and GitHub Release` step always runs for `workflow_dispatch` and uses `--target "$SHA"`.
### Fix Focus Areas
- .github/workflows/publish.yml[218-252]
### Suggested fix approach
- Emit an explicit output like `can_tag=true/false` (or `push_succeeded=true/false`) from the commit step.
- Update the `Create tag and GitHub Release (workflow_dispatch only)` step to run only when tagging is safe (e.g., when the bump was not needed, or the bump commit was successfully pushed).
- If tagging isn’t safe, fail the workflow (or at minimum skip tag creation and emit an `::error::`) so a maintainer can rerun from a stable `main` state.

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


3. Gitea push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitea.md builds the image as pr-agent:gitea_app but then pushes
pragent/pr-agent:gitea_webhook, which will fail because that tag was never built or retagged.
Code

docs/docs/installation/gitea.md[30]

+docker push pragent/pr-agent:gitea_webhook  # Push to your Docker repository
Evidence
The instructions build one tag and push a different tag with no intervening docker tag step, so
docker push will not find the referenced image locally.

docs/docs/installation/gitea.md[29-31]

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

## Issue description
`docs/docs/installation/gitea.md` instructs users to build an image tagged `pr-agent:gitea_app` and then push `pragent/pr-agent:gitea_webhook`. As written, `docker push` will fail because the pushed tag was never built locally.
### Issue Context
This was surfaced while renaming the Docker Hub namespace; the push target was updated but the build/tag flow in the snippet was not.
### Fix Focus Areas
- docs/docs/installation/gitea.md[29-31]
(Adjust the snippet so the `docker build -t ...` tag matches the `docker push ...` tag, or add an explicit `docker tag ...` step before pushing.)

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


View more (1)
4. GitLab push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitlab.md builds the image tagged gitlab_pr_agent but then pushes
pragent/pr-agent:gitlab_webhook, which will fail unless the image is retagged to that name first.
Code

docs/docs/installation/gitlab.md[79]

+docker push pragent/pr-agent:gitlab_webhook  # Push to your Docker repository
Evidence
The documented commands build an unqualified local tag (gitlab_pr_agent) and immediately push a
different fully-qualified tag (pragent/pr-agent:gitlab_webhook) without retagging, so the push
reference won’t exist locally.

docs/docs/installation/gitlab.md[77-80]

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

## Issue description
`docs/docs/installation/gitlab.md` tells users to build an image as `gitlab_pr_agent` and then push `pragent/pr-agent:gitlab_webhook`. Without a `docker tag gitlab_pr_agent pragent/pr-agent:gitlab_webhook` step (or building with the final tag), the push will fail.
### Issue Context
The push destination was updated as part of the Docker Hub namespace rename, but the build tag in the snippet remained unchanged.
### Fix Focus Areas
- docs/docs/installation/gitlab.md[77-80]
(Update the snippet so build and push use the same tag, or add a retagging step before pushing.)

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



Remediation recommended

5. Duplicate git clone comment 📘 Rule violation ⚙ Maintainability
Description
The updated Bitbucket provider example comment contains duplicated words (git clone git clone),
which is not concise and diverges from the project's comment style guidance. This reduces
readability and can confuse users copying the example.
Code

pr_agent/git_providers/bitbucket_provider.py[101]

+    # Example: git clone git clone https://bitbucket.org/pragent/pr-agent.git and branch: main -> prefix: "https://bitbucket.org/pragent/pr-agent/src/main", suffix: ""
Evidence
PR Compliance ID 11 requires modified comments to follow existing concise style; the changed comment
line includes an obvious duplicated phrase.

AGENTS.md
pr_agent/git_providers/bitbucket_provider.py[101-101]

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 modified comment contains duplicated text (`git clone git clone`), reducing clarity.
## Issue Context
This line was touched in the PR and should match the repo's concise comment style.
## Fix Focus Areas
- pr_agent/git_providers/bitbucket_provider.py[101-101]

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


6. SystemExit string single quotes 📘 Rule violation ⚙ Maintainability
Description
The new script raises SystemExit with a single-quoted string, which diverges from the repository’s
stated convention to use double quotes for strings. This introduces inconsistent formatting in newly
added Python code.
Code

scripts/set_pyproject_version.py[R31-33]

+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
Evidence
PR Compliance ID 9 requires new Python changes to follow existing formatting conventions including
double-quote string style; the added SystemExit message uses single quotes in the new script.

AGENTS.md
scripts/set_pyproject_version.py[31-33]

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 new Python script uses single-quoted string literals, but the repo’s formatting convention requires double quotes.
## Issue Context
This is a newly added script used by CI/release workflows; keeping formatting consistent reduces noisy diffs and style drift.
## Fix Focus Areas
- scripts/set_pyproject_version.py[31-33]

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


7. set_pyproject_version.py lacks IO handling 📘 Rule violation ☼ Reliability
Description
The new script performs read_text()/write_text() without handling OSError (missing file,
permission issues), which will surface as uncaught tracebacks in CI. This violates the requirement
to handle potential error scenarios gracefully.
Code

scripts/set_pyproject_version.py[R22-35]

+    path = pathlib.Path("pyproject.toml")
+    text = path.read_text()
+    new_text, count = re.subn(
+        r'^version = "[^"]+"',
+        f'version = "{version}"',
+        text,
+        count=1,
+        flags=re.MULTILINE,
+    )
+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
+    path.write_text(new_text)
+    print(f"Set pyproject.toml version to {version}")
Evidence
PR Compliance ID 3 requires robust error handling; the added script directly reads/writes
pyproject.toml without guarding for common filesystem failures.

Rule 3: Robust Error Handling
scripts/set_pyproject_version.py[22-35]

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

## Issue description
`scripts/set_pyproject_version.py` can crash with an uncaught exception if `pyproject.toml` is missing/unreadable or cannot be written.
## Issue Context
This script is used by the publish workflow; failures should provide a clear, actionable error message rather than a raw traceback.
## Fix Focus Areas
- scripts/set_pyproject_version.py[22-35]

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


Grey Divider

Previous review results

Review updated until commit 2c5bbe1

Results up to commit 2995ac1


🐞 Bugs (4) 📘 Rule violations (3)


Action required
1. E2E repo path mismatch 🐞 Bug ≡ Correctness ⭐ New
Description
tests/e2e_tests/test_gitlab_webhook.py now uses the GitLab project path pragent/pr-agent-tests,
but other E2E tests still reference codiumai/Codium-ai for the same fixtures repo, so the GitLab
E2E is likely to fail at gl.projects.get(repo_url) if the fixtures repo wasn’t migrated.
Code

tests/e2e_tests/test_gitlab_webhook.py[R29-30]

+    repo_url = 'pragent/pr-agent-tests'
    project = gl.projects.get(repo_url)
Evidence
The GitLab E2E test was switched to pragent/pr-agent-tests, but other E2E tests in this repo still
target Codium-ai/pr-agent-tests (GitHub) and codiumai (Bitbucket/Gitea), indicating the fixture
repository location is not consistently updated across the test suite.

tests/e2e_tests/test_gitlab_webhook.py[24-31]
tests/e2e_tests/test_github_app.py[23-36]
tests/e2e_tests/test_bitbucket_app.py[27-32]
tests/e2e_tests/test_gitea_app.py[22-26]

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 GitLab E2E test hard-codes a different `pr-agent-tests` repo path (`pragent/pr-agent-tests`) than the rest of the E2E tests (`codiumai` / `Codium-ai`), which can break CI by failing to resolve the project.

### Issue Context
This PR is a Docker image namespace migration; the E2E fixtures repo namespace/org may not have moved.

### Fix Focus Areas
- tests/e2e_tests/test_gitlab_webhook.py[24-31]

### What to change
- Pick the canonical fixture repo location for `pr-agent-tests` and make the GitLab E2E test match it.
- (Optional but safer) centralize the fixture repo owner/path in one place (e.g., settings/env var) so future namespace changes don’t require updating multiple tests.

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


2. Tag targets unbumped commit 🐞 Bug ≡ Correctness
Description
In workflow_dispatch publishes, if the version-bump commit cannot be pushed (non-fast-forward), the
workflow still creates a tag/release targeting the pre-bump commit SHA. This can produce a release
tag whose tree (pyproject.toml version) does not match the version used to build/publish PyPI and
Docker artifacts.
Code

.github/workflows/publish.yml[R224-252]

+          if git diff --quiet pyproject.toml; then
+            echo "pyproject.toml already at $VERSION on $PUBLISHED_SHA; nothing to commit."
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          git add pyproject.toml
+          git commit -m "chore(release): bump version to $VERSION [skip ci]"
+          if git push origin "HEAD:refs/heads/main"; then
+            echo "bumped=true" >> "$GITHUB_OUTPUT"
+            echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          else
+            echo "::warning::main has moved past the published commit ($PUBLISHED_SHA); skipping bump push and tag-move so the tag continues to point at built artifacts. Bump pyproject.toml on main manually:  git checkout main && python scripts/set_pyproject_version.py $VERSION && git commit -am 'chore(release): bump version to $VERSION' && git push"
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Create tag and GitHub Release (workflow_dispatch only)
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          GH_TOKEN: ${{ secrets.RELEASE_TOKEN || secrets.GITHUB_TOKEN }}
+          TAG: ${{ needs.prepare.outputs.tag }}
+          SHA: ${{ steps.commit.outputs.sha }}
+        run: |
+          if gh release view "$TAG" >/dev/null 2>&1; then
+            echo "Release $TAG already exists; not recreating."
+          else
+            gh release create "$TAG" --target "$SHA" --title "$TAG" --generate-notes
+          fi
Evidence
The commit step sets the output SHA back to the original published SHA when the push fails, but the
subsequent workflow_dispatch release creation unconditionally uses that SHA as the tag target,
despite the workflow’s own stated invariant about tags resolving to published trees.

.github/workflows/publish.yml[194-205]
.github/workflows/publish.yml[218-239]
.github/workflows/publish.yml[241-252]

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

## Issue description
On `workflow_dispatch`, the workflow can create a tag/Release pointing to `PUBLISHED_SHA` even when the bump commit couldn’t be pushed to `main`. That tag then references a commit whose `pyproject.toml` version may not match the version used to build/publish artifacts.
### Issue Context
In the `Commit & push bump` step, when `git push` fails, the step writes `sha=$PUBLISHED_SHA` to `$GITHUB_OUTPUT`. The subsequent `Create tag and GitHub Release` step always runs for `workflow_dispatch` and uses `--target "$SHA"`.
### Fix Focus Areas
- .github/workflows/publish.yml[218-252]
### Suggested fix approach
- Emit an explicit output like `can_tag=true/false` (or `push_succeeded=true/false`) from the commit step.
- Update the `Create tag and GitHub Release (workflow_dispatch only)` step to run only when tagging is safe (e.g., when the bump was not needed, or the bump commit was successfully pushed).
- If tagging isn’t safe, fail the workflow (or at minimum skip tag creation and emit an `::error::`) so a maintainer can rerun from a stable `main` state.

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


3. Gitea push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitea.md builds the image as pr-agent:gitea_app but then pushes
pragent/pr-agent:gitea_webhook, which will fail because that tag was never built or retagged.
Code

docs/docs/installation/gitea.md[30]

+docker push pragent/pr-agent:gitea_webhook  # Push to your Docker repository
Evidence
The instructions build one tag and push a different tag with no intervening docker tag step, so
docker push will not find the referenced image locally.

docs/docs/installation/gitea.md[29-31]

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

## Issue description
`docs/docs/installation/gitea.md` instructs users to build an image tagged `pr-agent:gitea_app` and then push `pragent/pr-agent:gitea_webhook`. As written, `docker push` will fail because the pushed tag was never built locally.
### Issue Context
This was surfaced while renaming the Docker Hub namespace; the push target was updated but the build/tag flow in the snippet was not.
### Fix Focus Areas
- docs/docs/installation/gitea.md[29-31]
(Adjust the snippet so the `docker build -t ...` tag matches the `docker push ...` tag, or add an explicit `docker tag ...` step before pushing.)

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


View more (1)
4. GitLab push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitlab.md builds the image tagged gitlab_pr_agent but then pushes
pragent/pr-agent:gitlab_webhook, which will fail unless the image is retagged to that name first.
Code

docs/docs/installation/gitlab.md[79]

+docker push pragent/pr-agent:gitlab_webhook  # Push to your Docker repository
Evidence
The documented commands build an unqualified local tag (gitlab_pr_agent) and immediately push a
different fully-qualified tag (pragent/pr-agent:gitlab_webhook) without retagging, so the push
reference won’t exist locally.

docs/docs/installation/gitlab.md[77-80]

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

## Issue description
`docs/docs/installation/gitlab.md` tells users to build an image as `gitlab_pr_agent` and then push `pragent/pr-agent:gitlab_webhook`. Without a `docker tag gitlab_pr_agent pragent/pr-agent:gitlab_webhook` step (or building with the final tag), the push will fail.
### Issue Context
The push destination was updated as part of the Docker Hub namespace rename, but the build tag in the snippet remained unchanged.
### Fix Focus Areas
- docs/docs/installation/gitlab.md[77-80]
(Update the snippet so build and push use the same tag, or add a retagging step before pushing.)

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



Remediation recommended
5. Duplicate git clone comment 📘 Rule violation ⚙ Maintainability ⭐ New
Description
The updated Bitbucket provider example comment contains duplicated words (git clone git clone),
which is not concise and diverges from the project's comment style guidance. This reduces
readability and can confuse users copying the example.
Code

pr_agent/git_providers/bitbucket_provider.py[101]

+    # Example: git clone git clone https://bitbucket.org/pragent/pr-agent.git and branch: main -> prefix: "https://bitbucket.org/pragent/pr-agent/src/main", suffix: ""
Evidence
PR Compliance ID 11 requires modified comments to follow existing concise style; the changed comment
line includes an obvious duplicated phrase.

AGENTS.md
pr_agent/git_providers/bitbucket_provider.py[101-101]

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 modified comment contains duplicated text (`git clone git clone`), reducing clarity.

## Issue Context
This line was touched in the PR and should match the repo's concise comment style.

## Fix Focus Areas
- pr_agent/git_providers/bitbucket_provider.py[101-101]

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


6. SystemExit string single quotes 📘 Rule violation ⚙ Maintainability
Description
The new script raises SystemExit with a single-quoted string, which diverges from the repository’s
stated convention to use double quotes for strings. This introduces inconsistent formatting in newly
added Python code.
Code

scripts/set_pyproject_version.py[R31-33]

+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
Evidence
PR Compliance ID 9 requires new Python changes to follow existing formatting conventions including
double-quote string style; the added SystemExit message uses single quotes in the new script.

AGENTS.md
scripts/set_pyproject_version.py[31-33]

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 new Python script uses single-quoted string literals, but the repo’s formatting convention requires double quotes.
## Issue Context
This is a newly added script used by CI/release workflows; keeping formatting consistent reduces noisy diffs and style drift.
## Fix Focus Areas
- scripts/set_pyproject_version.py[31-33]

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


7. set_pyproject_version.py lacks IO handling 📘 Rule violation ☼ Reliability
Description
The new script performs read_text()/write_text() without handling OSError (missing file,
permission issues), which will surface as uncaught tracebacks in CI. This violates the requirement
to handle potential error scenarios gracefully.
Code

scripts/set_pyproject_version.py[R22-35]

+    path = pathlib.Path("pyproject.toml")
+    text = path.read_text()
+    new_text, count = re.subn(
+        r'^version = "[^"]+"',
+        f'version = "{version}"',
+        text,
+        count=1,
+        flags=re.MULTILINE,
+    )
+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
+    path.write_text(new_text)
+    print(f"Set pyproject.toml version to {version}")
Evidence
PR Compliance ID 3 requires robust error handling; the added script directly reads/writes
pyproject.toml without guarding for common filesystem failures.

Rule 3: Robust Error Handling
scripts/set_pyproject_version.py[22-35]

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

## Issue description
`scripts/set_pyproject_version.py` can crash with an uncaught exception if `pyproject.toml` is missing/unreadable or cannot be written.
## Issue Context
This script is used by the publish workflow; failures should provide a clear, actionable error message rather than a raw traceback.
## Fix Focus Areas
- scripts/set_pyproject_version.py[22-35]

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


Results up to commit b1d6757


🐞 Bugs (3) 📘 Rule violations (2)


Action required
1. Tag targets unbumped commit 🐞 Bug ≡ Correctness
Description
In workflow_dispatch publishes, if the version-bump commit cannot be pushed (non-fast-forward), the
workflow still creates a tag/release targeting the pre-bump commit SHA. This can produce a release
tag whose tree (pyproject.toml version) does not match the version used to build/publish PyPI and
Docker artifacts.
Code

.github/workflows/publish.yml[R224-252]

+          if git diff --quiet pyproject.toml; then
+            echo "pyproject.toml already at $VERSION on $PUBLISHED_SHA; nothing to commit."
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          git add pyproject.toml
+          git commit -m "chore(release): bump version to $VERSION [skip ci]"
+          if git push origin "HEAD:refs/heads/main"; then
+            echo "bumped=true" >> "$GITHUB_OUTPUT"
+            echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          else
+            echo "::warning::main has moved past the published commit ($PUBLISHED_SHA); skipping bump push and tag-move so the tag continues to point at built artifacts. Bump pyproject.toml on main manually:  git checkout main && python scripts/set_pyproject_version.py $VERSION && git commit -am 'chore(release): bump version to $VERSION' && git push"
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Create tag and GitHub Release (workflow_dispatch only)
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          GH_TOKEN: ${{ secrets.RELEASE_TOKEN || secrets.GITHUB_TOKEN }}
+          TAG: ${{ needs.prepare.outputs.tag }}
+          SHA: ${{ steps.commit.outputs.sha }}
+        run: |
+          if gh release view "$TAG" >/dev/null 2>&1; then
+            echo "Release $TAG already exists; not recreating."
+          else
+            gh release create "$TAG" --target "$SHA" --title "$TAG" --generate-notes
+          fi
Evidence
The commit step sets the output SHA back to the original published SHA when the push fails, but the
subsequent workflow_dispatch release creation unconditionally uses that SHA as the tag target,
despite the workflow’s own stated invariant about tags resolving to published trees.

.github/workflows/publish.yml[194-205]
.github/workflows/publish.yml[218-239]
.github/workflows/publish.yml[241-252]

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

## Issue description
On `workflow_dispatch`, the workflow can create a tag/Release pointing to `PUBLISHED_SHA` even when the bump commit couldn’t be pushed to `main`. That tag then references a commit whose `pyproject.toml` version may not match the version used to build/publish artifacts.
### Issue Context
In the `Commit & push bump` step, when `git push` fails, the step writes `sha=$PUBLISHED_SHA` to `$GITHUB_OUTPUT`. The subsequent `Create tag and GitHub Release` step always runs for `workflow_dispatch` and uses `--target "$SHA"`.
### Fix Focus Areas
- .github/workflows/publish.yml[218-252]
### Suggested fix approach
- Emit an explicit output like `can_tag=true/false` (or `push_succeeded=true/false`) from the commit step.
- Update the `Create tag and GitHub Release (workflow_dispatch only)` step to run only when tagging is safe (e.g., when the bump was not needed, or the bump commit was successfully pushed).
- If tagging isn’t safe, fail the workflow (or at minimum skip tag creation and emit an `::error::`) so a maintainer can rerun from a stable `main` state.

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


2. Gitea push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitea.md builds the image as pr-agent:gitea_app but then pushes
pragent/pr-agent:gitea_webhook, which will fail because that tag was never built or retagged.
Code

docs/docs/installation/gitea.md[30]

+docker push pragent/pr-agent:gitea_webhook  # Push to your Docker repository
Evidence
The instructions build one tag and push a different tag with no intervening docker tag step, so
docker push will not find the referenced image locally.

docs/docs/installation/gitea.md[29-31]

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

## Issue description
`docs/docs/installation/gitea.md` instructs users to build an image tagged `pr-agent:gitea_app` and then push `pragent/pr-agent:gitea_webhook`. As written, `docker push` will fail because the pushed tag was never built locally.
### Issue Context
This was surfaced while renaming the Docker Hub namespace; the push target was updated but the build/tag flow in the snippet was not.
### Fix Focus Areas
- docs/docs/installation/gitea.md[29-31]
(Adjust the snippet so the `docker build -t ...` tag matches the `docker push ...` tag, or add an explicit `docker tag ...` step before pushing.)

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


3. GitLab push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitlab.md builds the image tagged gitlab_pr_agent but then pushes
pragent/pr-agent:gitlab_webhook, which will fail unless the image is retagged to that name first.
Code

docs/docs/installation/gitlab.md[79]

+docker push pragent/pr-agent:gitlab_webhook  # Push to your Docker repository
Evidence
The documented commands build an unqualified local tag (gitlab_pr_agent) and immediately push a
different fully-qualified tag (pragent/pr-agent:gitlab_webhook) without retagging, so the push
reference won’t exist locally.

docs/docs/installation/gitlab.md[77-80]

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

## Issue description
`docs/docs/installation/gitlab.md` tells users to build an image as `gitlab_pr_agent` and then push `pragent/pr-agent:gitlab_webhook`. Without a `docker tag gitlab_pr_agent pragent/pr-agent:gitlab_webhook` step (or building with the final tag), the push will fail.
### Issue Context
The push destination was updated as part of the Docker Hub namespace rename, but the build tag in the snippet remained unchanged.
### Fix Focus Areas
- docs/docs/installation/gitlab.md[77-80]
(Update the snippet so build and push use the same tag, or add a retagging step before pushing.)

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



Remediation recommended
4. SystemExit string single quotes 📘 Rule violation ⚙ Maintainability
Description
The new script raises SystemExit with a single-quoted string, which diverges from the repository’s
stated convention to use double quotes for strings. This introduces inconsistent formatting in newly
added Python code.
Code

scripts/set_pyproject_version.py[R31-33]

+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
Evidence
PR Compliance ID 9 requires new Python changes to follow existing formatting conventions including
double-quote string style; the added SystemExit message uses single quotes in the new script.

AGENTS.md
scripts/set_pyproject_version.py[31-33]

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 new Python script uses single-quoted string literals, but the repo’s formatting convention requires double quotes.
## Issue Context
This is a newly added script used by CI/release workflows; keeping formatting consistent reduces noisy diffs and style drift.
## Fix Focus Areas
- scripts/set_pyproject_version.py[31-33]

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


5. set_pyproject_version.py lacks IO handling 📘 Rule violation ☼ Reliability
Description
The new script performs read_text()/write_text() without handling OSError (missing file,
permission issues), which will surface as uncaught tracebacks in CI. This violates the requirement
to handle potential error scenarios gracefully.
Code

scripts/set_pyproject_version.py[R22-35]

+    path = pathlib.Path("pyproject.toml")
+    text = path.read_text()
+    new_text, count = re.subn(
+        r'^version = "[^"]+"',
+        f'version = "{version}"',
+        text,
+        count=1,
+        flags=re.MULTILINE,
+    )
+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
+    path.write_text(new_text)
+    print(f"Set pyproject.toml version to {version}")
Evidence
PR Compliance ID 3 requires robust error handling; the added script directly reads/writes
pyproject.toml without guarding for common filesystem failures.

Rule 3: Robust Error Handling
scripts/set_pyproject_version.py[22-35]

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

## Issue description
`scripts/set_pyproject_version.py` can crash with an uncaught exception if `pyproject.toml` is missing/unreadable or cannot be written.
## Issue Context
This script is used by the publish workflow; failures should provide a clear, actionable error message rather than a raw traceback.
## Fix Focus Areas
- scripts/set_pyproject_version.py[22-35]

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


Results up to commit ca02e14


🐞 Bugs (3) 📘 Rule violations (2)


Action required
1. Tag targets unbumped commit 🐞 Bug ≡ Correctness ⭐ New
Description
In workflow_dispatch publishes, if the version-bump commit cannot be pushed (non-fast-forward), the
workflow still creates a tag/release targeting the pre-bump commit SHA. This can produce a release
tag whose tree (pyproject.toml version) does not match the version used to build/publish PyPI and
Docker artifacts.
Code

.github/workflows/publish.yml[R224-252]

+          if git diff --quiet pyproject.toml; then
+            echo "pyproject.toml already at $VERSION on $PUBLISHED_SHA; nothing to commit."
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          git add pyproject.toml
+          git commit -m "chore(release): bump version to $VERSION [skip ci]"
+          if git push origin "HEAD:refs/heads/main"; then
+            echo "bumped=true" >> "$GITHUB_OUTPUT"
+            echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          else
+            echo "::warning::main has moved past the published commit ($PUBLISHED_SHA); skipping bump push and tag-move so the tag continues to point at built artifacts. Bump pyproject.toml on main manually:  git checkout main && python scripts/set_pyproject_version.py $VERSION && git commit -am 'chore(release): bump version to $VERSION' && git push"
+            echo "bumped=false" >> "$GITHUB_OUTPUT"
+            echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Create tag and GitHub Release (workflow_dispatch only)
+        if: github.event_name == 'workflow_dispatch'
+        env:
+          GH_TOKEN: ${{ secrets.RELEASE_TOKEN || secrets.GITHUB_TOKEN }}
+          TAG: ${{ needs.prepare.outputs.tag }}
+          SHA: ${{ steps.commit.outputs.sha }}
+        run: |
+          if gh release view "$TAG" >/dev/null 2>&1; then
+            echo "Release $TAG already exists; not recreating."
+          else
+            gh release create "$TAG" --target "$SHA" --title "$TAG" --generate-notes
+          fi
Evidence
The commit step sets the output SHA back to the original published SHA when the push fails, but the
subsequent workflow_dispatch release creation unconditionally uses that SHA as the tag target,
despite the workflow’s own stated invariant about tags resolving to published trees.

.github/workflows/publish.yml[194-205]
.github/workflows/publish.yml[218-239]
.github/workflows/publish.yml[241-252]

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

### Issue description
On `workflow_dispatch`, the workflow can create a tag/Release pointing to `PUBLISHED_SHA` even when the bump commit couldn’t be pushed to `main`. That tag then references a commit whose `pyproject.toml` version may not match the version used to build/publish artifacts.

### Issue Context
In the `Commit & push bump` step, when `git push` fails, the step writes `sha=$PUBLISHED_SHA` to `$GITHUB_OUTPUT`. The subsequent `Create tag and GitHub Release` step always runs for `workflow_dispatch` and uses `--target "$SHA"`.

### Fix Focus Areas
- .github/workflows/publish.yml[218-252]

### Suggested fix approach
- Emit an explicit output like `can_tag=true/false` (or `push_succeeded=true/false`) from the commit step.
- Update the `Create tag and GitHub Release (workflow_dispatch only)` step to run only when tagging is safe (e.g., when the bump was not needed, or the bump commit was successfully pushed).
- If tagging isn’t safe, fail the workflow (or at minimum skip tag creation and emit an `::error::`) so a maintainer can rerun from a stable `main` state.

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


2. Gitea push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitea.md builds the image as pr-agent:gitea_app but then pushes
pragent/pr-agent:gitea_webhook, which will fail because that tag was never built or retagged.
Code

docs/docs/installation/gitea.md[30]

+docker push pragent/pr-agent:gitea_webhook  # Push to your Docker repository
Evidence
The instructions build one tag and push a different tag with no intervening docker tag step, so
docker push will not find the referenced image locally.

docs/docs/installation/gitea.md[29-31]

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

## Issue description
`docs/docs/installation/gitea.md` instructs users to build an image tagged `pr-agent:gitea_app` and then push `pragent/pr-agent:gitea_webhook`. As written, `docker push` will fail because the pushed tag was never built locally.
### Issue Context
This was surfaced while renaming the Docker Hub namespace; the push target was updated but the build/tag flow in the snippet was not.
### Fix Focus Areas
- docs/docs/installation/gitea.md[29-31]
(Adjust the snippet so the `docker build -t ...` tag matches the `docker push ...` tag, or add an explicit `docker tag ...` step before pushing.)

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


3. GitLab push tag mismatch 🐞 Bug ≡ Correctness
Description
docs/docs/installation/gitlab.md builds the image tagged gitlab_pr_agent but then pushes
pragent/pr-agent:gitlab_webhook, which will fail unless the image is retagged to that name first.
Code

docs/docs/installation/gitlab.md[79]

+docker push pragent/pr-agent:gitlab_webhook  # Push to your Docker repository
Evidence
The documented commands build an unqualified local tag (gitlab_pr_agent) and immediately push a
different fully-qualified tag (pragent/pr-agent:gitlab_webhook) without retagging, so the push
reference won’t exist locally.

docs/docs/installation/gitlab.md[77-80]

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

## Issue description
`docs/docs/installation/gitlab.md` tells users to build an image as `gitlab_pr_agent` and then push `pragent/pr-agent:gitlab_webhook`. Without a `docker tag gitlab_pr_agent pragent/pr-agent:gitlab_webhook` step (or building with the final tag), the push will fail.
### Issue Context
The push destination was updated as part of the Docker Hub namespace rename, but the build tag in the snippet remained unchanged.
### Fix Focus Areas
- docs/docs/installation/gitlab.md[77-80]
(Update the snippet so build and push use the same tag, or add a retagging step before pushing.)

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



Remediation recommended
4. SystemExit string single quotes 📘 Rule violation ⚙ Maintainability ⭐ New
Description
The new script raises SystemExit with a single-quoted string, which diverges from the repository’s
stated convention to use double quotes for strings. This introduces inconsistent formatting in newly
added Python code.
Code

scripts/set_pyproject_version.py[R31-33]

+    if count != 1:
+        raise SystemExit('Could not locate `version = "..."` in pyproject.toml')
+
Evidence
PR Compliance ID 9 requires new Python changes to follow existing formatting conventions including
double-quote string style; the added SystemExit message uses single quotes in the new script.

AGENTS.md
scripts/set_pyproject_version.py[31-33]

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 new Python script uses single-quoted string literals, but the repo’s formatting convention requires double quotes.

## Issue Context
This is a newly added script used by CI/release workflows; keeping formatting consistent reduces noisy diffs and style drift.

## Fix Focus Areas
- scripts/set_pyproject_version.py[31-33]

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


5. set_pyproject_version.py lacks IO handling 📘 Rule violation ☼ Reliability ⭐ New
Details

```bash
docker build -f /docker/Dockerfile -t pr-agent:gitea_app --target gitea_app .
docker push codiumai/pr-agent:gitea_webhook # Push to your Docker repository
docker push pragent/pr-agent:gitea_webhook # Push to your Docker repository
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

1. Gitea push tag mismatch 🐞 Bug ≡ Correctness

docs/docs/installation/gitea.md builds the image as pr-agent:gitea_app but then pushes
pragent/pr-agent:gitea_webhook, which will fail because that tag was never built or retagged.
Agent Prompt
### Issue description
`docs/docs/installation/gitea.md` instructs users to build an image tagged `pr-agent:gitea_app` and then push `pragent/pr-agent:gitea_webhook`. As written, `docker push` will fail because the pushed tag was never built locally.

### Issue Context
This was surfaced while renaming the Docker Hub namespace; the push target was updated but the build/tag flow in the snippet was not.

### Fix Focus Areas
- docs/docs/installation/gitea.md[29-31]

(Adjust the snippet so the `docker build -t ...` tag matches the `docker push ...` tag, or add an explicit `docker tag ...` step before pushing.)

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

```bash
docker build . -t gitlab_pr_agent --target gitlab_webhook -f docker/Dockerfile
docker push codiumai/pr-agent:gitlab_webhook # Push to your Docker repository
docker push pragent/pr-agent:gitlab_webhook # Push to your Docker repository
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

2. Gitlab push tag mismatch 🐞 Bug ≡ Correctness

docs/docs/installation/gitlab.md builds the image tagged gitlab_pr_agent but then pushes
pragent/pr-agent:gitlab_webhook, which will fail unless the image is retagged to that name first.
Agent Prompt
### Issue description
`docs/docs/installation/gitlab.md` tells users to build an image as `gitlab_pr_agent` and then push `pragent/pr-agent:gitlab_webhook`. Without a `docker tag gitlab_pr_agent pragent/pr-agent:gitlab_webhook` step (or building with the final tag), the push will fail.

### Issue Context
The push destination was updated as part of the Docker Hub namespace rename, but the build tag in the snippet remained unchanged.

### Fix Focus Areas
- docs/docs/installation/gitlab.md[77-80]

(Update the snippet so build and push use the same tag, or add a retagging step before pushing.)

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

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR migrates all documented and CI references of the PR-Agent Docker image from the codiumai/pr-agent namespace to pragent/pr-agent, aligning workflows, docs, and the GitHub Action’s base image with the new Docker Hub repository.

Changes:

  • Updated GitHub workflows to build/test/publish images under pragent/pr-agent.
  • Updated the GitHub Action Dockerfile base image to pull from pragent/pr-agent:github_action.
  • Updated installation/security/docs references (docker run, image:, and docker://...) to the new namespace.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
.github/workflows/publish.yml Publishes release tags to pragent/pr-agent:* instead of codiumai/pr-agent:*.
.github/workflows/build-and-test.yaml Uses pragent/pr-agent:test for local CI build + unit tests.
.github/workflows/code_coverage.yaml Uses pragent/pr-agent:test for local CI build + coverage run.
.github/workflows/e2e_tests.yaml Uses pragent/pr-agent:test for local CI build + E2E runs.
Dockerfile.github_action_dockerhub Switches GitHub Action base image to pragent/pr-agent:github_action.
SECURITY.md Updates pinned example image reference to the new namespace.
docs/docs/tools/help_docs.md Updates docker://... example image reference to the new namespace.
docs/docs/installation/locally.md Updates local docker run examples to pull from pragent/pr-agent.
docs/docs/installation/github.md Updates GitHub Action docker://... examples and Docker Hub link to the new namespace.
docs/docs/installation/gitlab.md Updates GitLab pipeline image: and push/tag examples to the new namespace.
docs/docs/installation/bitbucket.md Updates Bitbucket pipeline image: and push examples to the new namespace.
docs/docs/installation/azure.md Updates Azure pipeline container image to the new namespace.
docs/docs/installation/gitea.md Updates Docker push example to the new namespace.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@@ -76,7 +76,7 @@ git clone https://github.com/the-pr-agent/pr-agent.git

```bash
docker build . -t gitlab_pr_agent --target gitlab_webhook -f docker/Dockerfile
@@ -27,7 +27,7 @@ git clone https://github.com/the-pr-agent/pr-agent.git

```bash
docker build -f /docker/Dockerfile -t pr-agent:gitea_app --target gitea_app .
Comment thread SECURITY.md
Comment on lines 49 to 56
For maximum security, you can specify the Docker image using its digest:

```yaml
steps:
- name: PR Agent action step
id: pragent
uses: docker://codiumai/pr-agent@sha256:14165e525678ace7d9b51cda8652c2d74abb4e1d76b57c4a6ccaeba84663cc64
uses: docker://pragent/pr-agent@sha256:14165e525678ace7d9b51cda8652c2d74abb4e1d76b57c4a6ccaeba84663cc64
```
Comment on lines +500 to 507
For enhanced security, you can also specify the Docker image by its [digest](https://hub.docker.com/repository/docker/pragent/pr-agent/tags):
```yaml
...
steps:
- name: PR Agent action step
id: pragent
uses: docker://codiumai/pr-agent@sha256:14165e525678ace7d9b51cda8652c2d74abb4e1d76b57c4a6ccaeba84663cc64
uses: docker://pragent/pr-agent@sha256:14165e525678ace7d9b51cda8652c2d74abb4e1d76b57c4a6ccaeba84663cc64
...
Base automatically changed from ci/release-workflow to main May 2, 2026 19:37
@naorpeled naorpeled force-pushed the ci/rename-registry branch from 8c6d72a to ca02e14 Compare May 2, 2026 19:40
@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

qodo-free-for-open-source-projects Bot commented May 2, 2026

Persistent review updated to latest commit ca02e14

Comment on lines +224 to +252
if git diff --quiet pyproject.toml; then
echo "pyproject.toml already at $VERSION on $PUBLISHED_SHA; nothing to commit."
echo "bumped=false" >> "$GITHUB_OUTPUT"
echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
exit 0
fi
git add pyproject.toml
git commit -m "chore(release): bump version to $VERSION [skip ci]"
if git push origin "HEAD:refs/heads/main"; then
echo "bumped=true" >> "$GITHUB_OUTPUT"
echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
else
echo "::warning::main has moved past the published commit ($PUBLISHED_SHA); skipping bump push and tag-move so the tag continues to point at built artifacts. Bump pyproject.toml on main manually: git checkout main && python scripts/set_pyproject_version.py $VERSION && git commit -am 'chore(release): bump version to $VERSION' && git push"
echo "bumped=false" >> "$GITHUB_OUTPUT"
echo "sha=$PUBLISHED_SHA" >> "$GITHUB_OUTPUT"
fi

- name: Create tag and GitHub Release (workflow_dispatch only)
if: github.event_name == 'workflow_dispatch'
env:
GH_TOKEN: ${{ secrets.RELEASE_TOKEN || secrets.GITHUB_TOKEN }}
TAG: ${{ needs.prepare.outputs.tag }}
SHA: ${{ steps.commit.outputs.sha }}
run: |
if gh release view "$TAG" >/dev/null 2>&1; then
echo "Release $TAG already exists; not recreating."
else
gh release create "$TAG" --target "$SHA" --title "$TAG" --generate-notes
fi
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

1. Tag targets unbumped commit 🐞 Bug ≡ Correctness

In workflow_dispatch publishes, if the version-bump commit cannot be pushed (non-fast-forward), the
workflow still creates a tag/release targeting the pre-bump commit SHA. This can produce a release
tag whose tree (pyproject.toml version) does not match the version used to build/publish PyPI and
Docker artifacts.
Agent Prompt
### Issue description
On `workflow_dispatch`, the workflow can create a tag/Release pointing to `PUBLISHED_SHA` even when the bump commit couldn’t be pushed to `main`. That tag then references a commit whose `pyproject.toml` version may not match the version used to build/publish artifacts.

### Issue Context
In the `Commit & push bump` step, when `git push` fails, the step writes `sha=$PUBLISHED_SHA` to `$GITHUB_OUTPUT`. The subsequent `Create tag and GitHub Release` step always runs for `workflow_dispatch` and uses `--target "$SHA"`.

### Fix Focus Areas
- .github/workflows/publish.yml[218-252]

### Suggested fix approach
- Emit an explicit output like `can_tag=true/false` (or `push_succeeded=true/false`) from the commit step.
- Update the `Create tag and GitHub Release (workflow_dispatch only)` step to run only when tagging is safe (e.g., when the bump was not needed, or the bump commit was successfully pushed).
- If tagging isn’t safe, fail the workflow (or at minimum skip tag creation and emit an `::error::`) so a maintainer can rerun from a stable `main` state.

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

@naorpeled naorpeled force-pushed the ci/rename-registry branch from ca02e14 to b1d6757 Compare May 2, 2026 19:52
@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

qodo-free-for-open-source-projects Bot commented May 2, 2026

Persistent review updated to latest commit b1d6757

@naorpeled naorpeled force-pushed the ci/rename-registry branch from b1d6757 to 2995ac1 Compare May 2, 2026 19:55
@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

qodo-free-for-open-source-projects Bot commented May 2, 2026

Persistent review updated to latest commit 2995ac1

Comment on lines +29 to 30
repo_url = 'pragent/pr-agent-tests'
project = gl.projects.get(repo_url)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Action required

1. E2e repo path mismatch 🐞 Bug ≡ Correctness

tests/e2e_tests/test_gitlab_webhook.py now uses the GitLab project path pragent/pr-agent-tests,
but other E2E tests still reference codiumai/Codium-ai for the same fixtures repo, so the GitLab
E2E is likely to fail at gl.projects.get(repo_url) if the fixtures repo wasn’t migrated.
Agent Prompt
### Issue description
The GitLab E2E test hard-codes a different `pr-agent-tests` repo path (`pragent/pr-agent-tests`) than the rest of the E2E tests (`codiumai` / `Codium-ai`), which can break CI by failing to resolve the project.

### Issue Context
This PR is a Docker image namespace migration; the E2E fixtures repo namespace/org may not have moved.

### Fix Focus Areas
- tests/e2e_tests/test_gitlab_webhook.py[24-31]

### What to change
- Pick the canonical fixture repo location for `pr-agent-tests` and make the GitLab E2E test match it.
- (Optional but safer) centralize the fixture repo owner/path in one place (e.g., settings/env var) so future namespace changes don’t require updating multiple tests.

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

@naorpeled naorpeled force-pushed the ci/rename-registry branch from 2995ac1 to 77c6dda Compare May 2, 2026 20:00
@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

qodo-free-for-open-source-projects Bot commented May 2, 2026

Code Review by Qodo

Grey Divider

New Review Started

This review has been superseded by a new analysis

Grey Divider

Qodo Logo

The release pipeline now publishes images under pragent/pr-agent (see
#2361). Update user-facing docs and the local :test tag in CI to match
so docker pull / image: examples resolve to images that actually exist.

RELEASE_NOTES.md is left as-is (historical record of past publishes).
Code comments in bitbucket_provider.py / gitlab_provider.py reference
git URLs (.git repos) not docker images, and tests/e2e_tests refers
to codiumai/pr-agent-tests which is a separate fixtures repo — both
intentionally untouched.
@naorpeled naorpeled force-pushed the ci/rename-registry branch from 77c6dda to 2c5bbe1 Compare May 2, 2026 20:01
@qodo-free-for-open-source-projects
Copy link
Copy Markdown
Contributor

qodo-free-for-open-source-projects Bot commented May 2, 2026

Persistent review updated to latest commit 2c5bbe1

@naorpeled naorpeled merged commit bf069a6 into main May 2, 2026
3 checks passed
@naorpeled naorpeled deleted the ci/rename-registry branch May 2, 2026 20:08
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