asf-tooling commented on issue #139:
URL:
https://github.com/apache/tooling-trusted-releases/issues/139#issuecomment-4410446240
<!-- gofannon-issue-triage-bot v2 -->
**Automated triage** — analyzed at `main@2da7807a`
**Type:** `new_feature` • **Classification:** `no_action` •
**Confidence:** `high`
**Application domain(s):** `project_committee_management`,
`shared_infrastructure`
### Summary
This issue proposes allowing Apache projects to be defined declaratively via
`.asf.yaml` configuration. The prior discussion clarifies that the primary
implementation lives in the external `apache/infrastructure-asfyaml` repository
(adding a `projects.py` feature there), which would then call an ATR API
endpoint to create/update projects. @dave2wave noted (2026-02-04) that the next
step is to add `projects.py` to the external repo's feature directory. ATR's
role is to expose an API endpoint that the asfyaml processing will call, but no
concrete endpoint design has been finalized yet.
### Where new code would go
- `atr/api/__init__.py` — after existing API route definitions
ATR needs a new API endpoint (likely POST) that the infrastructure-asfyaml
processing can call to create/update project definitions. Per the architecture,
JSON API routes live here.
- `atr/models/api.py` — new Pydantic model for project creation/update
request
A request model would be needed to validate the project metadata fields
sent by the asfyaml processor.
### Proposed approach
The implementation has two parts: (1) In the external
`apache/infrastructure-asfyaml` repository, add a `projects.py` feature module
that parses the `projects:` section of `.asf.yaml` and calls ATR's API. (2) In
this repository, expose an API endpoint (likely under `atr/api/`) that accepts
project metadata (name, description, keys, tags, etc.) and creates or updates
the project in ATR's database via the storage layer. Additionally, @dave2wave
mentioned an endpoint to export a project's current configuration as YAML.
Since the primary next step is in the external repo and I don't have access to
the ATR application source files (only config/CI files were provided), I cannot
propose concrete diffs for the ATR-side endpoint. The team should coordinate
with the infrastructure-asfyaml repo to define the API contract first.
### Open questions
- What authentication mechanism will the asfyaml processor use to call the
ATR endpoint? (Service token, mTLS, or something else?)
- What is the exact schema for the project creation/update payload that the
endpoint should accept?
- Should the endpoint be idempotent (create-or-update) or separate
create/update operations?
- Is there a timeline for the infrastructure-asfyaml side implementation
that would drive ATR endpoint development?
- How will authorization work - should the endpoint verify that the calling
repo belongs to the PMC that owns the project?
_The agent reviewed this issue and is not proposing patches in this run.
Review the existing-code citations and open questions above before deciding
next steps._
### Files examined
- `.asf.yaml`
- `.github/PULL_REQUEST_TEMPLATE.md`
- `.github/dependabot.yml`
- `.github/labeler.yml`
- `.github/linters/.markdown-lint.yml`
- `.github/workflows/allowlistchecker.yml`
- `.github/workflows/analyze.yml`
- `.github/workflows/build.yml`
---
*Draft from a triage agent. A human reviewer should validate before merging
any change. The agent did not run tests or verify diffs apply.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
