refactor: simplify AWS CodeArtifact publishing to use AWS secrets + PYPI_REPOSITORY_URL

[Copilot]

Summary

Simplifies the AWS CodeArtifact publishing support by integrating it directly into the existing PyPI publishing job, rather than as a separate workflow job. Users configure just three items: two GitHub Secrets (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) and one GitHub Variable (PYPI_REPOSITORY_URL pointing to the CodeArtifact endpoint). The workflow auto-detects CodeArtifact URLs and handles token exchange transparently.

Changes

GitHub Actions (.github/workflows/rhiza_release.yml):

• Removed the separate codeartifact job — CodeArtifact is now handled inline in the pypi job
• Added "Get AWS CodeArtifact token" step that auto-detects CodeArtifact URLs in PYPI_REPOSITORY_URL, parses domain/region, and fetches a temporary auth token using AWS secrets
• Updated the publish step to use the CodeArtifact token (with aws username) when available, falling back to PYPI_TOKEN or OIDC
• Updated Private :: Do Not Upload check: now only blocks publishing to default PyPI — custom feeds (including CodeArtifact) still publish
• Removed codeartifact from finalise-release dependencies and link generation

GitLab CI (.gitlab/workflows/rhiza_release.yml):

• Removed the separate release:codeartifact job — same inline integration into release:pypi
• Added CodeArtifact auto-detection and token handling with error handling
• Updated release:finalize to remove codeartifact dependency

Documentation:

• .rhiza/docs/RELEASING.md: simplified CodeArtifact setup to 3 configuration items with step-by-step instructions
• docs/ARCHITECTURE.md: updated release pipeline diagram (removed separate CodeArtifact box)
• docs/PRESENTATION.md, docs/CHANGELOG_GUIDE.md, .gitlab/TESTING.md, .gitlab/README.md: updated to reflect simplified approach

User configuration (all that's needed for CodeArtifact):

Type	Name	Description
Secret	AWS_ACCESS_KEY_ID	IAM user access key
Secret	AWS_SECRET_ACCESS_KEY	IAM user secret key
Variable	PYPI_REPOSITORY_URL	CodeArtifact endpoint URL

No OIDC setup, no domain/repository variables, no separate job. The workflow auto-detects CodeArtifact URLs and handles everything.

Testing

• make test passes locally
• make fmt has been run (actionlint, shellcheck, markdownlint all pass)
• New tests added (or explain why not needed)
  • Workflow YAML validated via actionlint and check-jsonschema pre-commit hooks. Both YAML files parsed and structurally verified. No unit-testable application code was changed.

Checklist

• Commit messages follow the Conventional Commits format
• Documentation updated if behaviour changed
• make deptry passes (no unused or missing dependencies)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Extension to release to AWS CodeArtifact</issue_title>
<issue_description>### Problem / motivation

Not clear if this is already supported. If not, let's extend ...

possibly required in rhiza_release.yml?

- name: Configure AWS credentials
  if: ${{ steps.check_dist.outputs.should_publish == 'true' }}
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ vars.AWS_ROLE_ARN }}
    aws-region: eu-west-2

- name: Get CodeArtifact token
  if: ${{ steps.check_dist.outputs.should_publish == 'true' }}
  id: codeartifact
  run: |
    TOKEN=$(aws codeartifact get-authorization-token \
      --domain ringfinity --region eu-west-2 \
      --query authorizationToken --output text)
    echo "::add-mask::$TOKEN"
    echo "token=$TOKEN" >> "$GITHUB_OUTPUT"

Proposed solution

Let's get claude to see what (if anything) is required to get this running.

Alternatives considered

No response

Additional context

No response</issue_description>

<agent_instructions>Let's figure this out in the most general terms. Once solved, provide crystal clear instructions for any additional config required by the user</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Extension to release to AWS CodeArtifact #885

---

📍 Connect Copilot coding agent with Jira, Azure Boards or Linear to delegate work to Copilot in one click without leaving your project management tool.

[markrichardson]

@tschm @HarryCampion ... reasonable?

[HarryCampion]

@tschm @HarryCampion ... reasonable?

If we're going down the route of very custom deployments like this we should split these into actions. Release will get very big otherwise.

I have not used AWS CodeArtifact before. What's the use case?

[markrichardson]

We would want to eventually have a number of standard options catered for out of the box: PyPi (done already as the standard), but also Azure, AWS, Nexus. So some way of the rhiza user abstractly specifying what they want in this regard upfront would be good. Thinking about the way bundles work, something simliar would be useful here. (User states in a yaml somehow ... "I am publishing artifacts to AWS, not PyPi, here are all the details you need to make it happen")

[HarryCampion]

We would want to eventually have a number of standard options catered for out of the box: PyPi (done already as the standard), but also Azure, AWS, Nexus. So some way of the rhiza user abstractly specifying what they want in this regard upfront would be good. Thinking about the way bundles work, something simliar would be useful here. (User states in a yaml somehow ... "I am publishing artifacts to AWS, not PyPi, here are all the details you need to make it happen")

Think most get covered by the action we use if twine can upload, otherwise makes sense. They need to be actions that can be included and excluded in the template, other rhiza release is going to bundle too much into one workflow.

[markrichardson]

it looks like twine can be used. but claude thinks it needs changes to the the rhiza-release.yml also

[tschm]

@HarryCampion the "make release" flow is genuinely excellent it just works, which is very appreciated.

It also looks like you already have the right infrastructure in place to test all of this properly.

Have you come across JFrog? They’ve built quite a comprehensive ecosystem around artifact management and CI/CD.

That said, Astral seems to be working on something that could potentially leapfrog a lot of the existing solutions.

[HarryCampion]

@claude[agent] I think it would be great to support additional endpoints for artifact feeds. Could you please refactor the release pipeline to allow different release actions to be injected depending on the 'artifact provider/storage mechanism'. This will eventually mean a user can define at the .rhiza/template.yml level what artifact feed they are using and not have to worry about configuring the release mechanism and also the rhiza release workflow is then not polluted.

[Claude]

@claude[agent] I think it would be great to support additional endpoints for artifact feeds. Could you please refactor the release pipeline to allow different release actions to be injected depending ...

I understand the goal of making release targets configurable and preventing workflow bloat. However, I need to clarify the scope and approach before proceeding with this refactor.

Current Architecture Analysis:
The release workflows are already opt-in via repository variables:

• PyPI: Skips if Private :: Do Not Upload classifier present
• CodeArtifact: Skips if AWS_CODEARTIFACT_DOMAIN not set
• Devcontainer: Skips if PUBLISH_DEVCONTAINER != "true"

Concerns with Proposed Approach:

1. GitHub Actions Limitations: Unlike bundles (which are file-based templates), GitHub Actions can't dynamically compose workflow jobs at runtime. Workflow files must be complete and valid YAML before execution starts.

2. Template System Scope: The .rhiza/template.yml and bundle system controls which files are synced to downstream projects, but it doesn't support conditional job injection within a single workflow file.

3. Complexity vs. Value: Creating an abstraction layer for "injectable release actions" would require:

   • A new configuration schema in .rhiza/template.yml
   • Template preprocessing/generation logic
   • Maintaining multiple workflow variants
   • This adds significant complexity for what's currently 3 opt-in jobs

Proposed Alternative:
Instead of refactoring the monolithic workflow, we could:

1. Split each publishing target into a reusable workflow (.github/workflows/publish-*.yml)
2. Keep the main rhiza_release.yml as a coordinator that calls these reusable workflows
3. Users can then override/customize individual publish workflows or disable them via variables

Would you like me to explore this reusable workflow approach, or would you prefer a different strategy? I want to ensure we solve the right problem before making significant architectural changes.

[markrichardson]

@copilot

please ensure the user can configure AWS CodeArtifact within Rhiza via provision of the following:

Set two GitHub Secrets: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
Set one GitHub Variable: PYPI_REPOSITORY_URL (for publishing)

[Copilot]

@copilot

please ensure the user can configure AWS CodeArtifact within Rhiza via provision of the following:
...

Done in f501825. Removed the separate codeartifact job from both GitHub Actions and GitLab CI workflows. CodeArtifact support is now integrated into the existing pypi job — it auto-detects CodeArtifact URLs in PYPI_REPOSITORY_URL and fetches a temporary auth token using the AWS secrets.

Configuration is just 3 items:

• Secret AWS_ACCESS_KEY_ID — IAM user access key
• Secret AWS_SECRET_ACCESS_KEY — IAM user secret key
• Variable PYPI_REPOSITORY_URL — CodeArtifact endpoint (get it via aws codeartifact get-repository-endpoint)

The Private :: Do Not Upload classifier now only blocks publishing to default PyPI — when PYPI_REPOSITORY_URL is set (e.g. CodeArtifact), private packages still publish. Full setup instructions in .rhiza/docs/RELEASING.md.

[HarryCampion]

@markrichardson can you point dummyrepo at this to test publishing mechanism still works. E..g PRIVATE is not publishing?

[markrichardson]

I don't think we ever set up dummyrepo to publish to pypi even so not sure what we could validate (or invalidate) doing this

[HarryCampion]

I don't think we ever set up dummyrepo to publish to pypi even so not sure what we could validate (or invalidate) doing this

It would confirm the path it takes for deployment. It shouldn't publish.

[markrichardson]

see markrichardson/dummyrepo#86