asf-tooling commented on issue #914:
URL: 
https://github.com/apache/tooling-trusted-releases/issues/914#issuecomment-4410045242

   <!-- gofannon-issue-triage-bot v2 -->
   
   **Automated triage** — analyzed at `main@2da7807a`
   
   **Type:** `new_feature`  •  **Classification:** `no_action`  •  
**Confidence:** `high`  •  ⚠️ **Stale — consider closing**
   **Application domain(s):** `shared_infrastructure`, `release_lifecycle`
   
   ### Summary
   Issue #914 requests a lifecycle event data model with specific fields 
(project_key, cycle_key, version_key, event type, datetime, reference URLs) and 
search indexes. This feature has already been fully implemented: the database 
migration (0076), the LifecycleEventType enum, the LifecycleEvent model, the 
ECMA-428 CLE document generator (atr/cle.py), and comprehensive unit tests 
(tests/unit/test_cle.py) all exist in the codebase. The prior discussion 
between @ppkarwasz, @sbp, and @dave2wave about 'end of support' vs 'end of 
maintenance' terminology was resolved in favor of 'eos' (end of support) per 
ECMA-428 § 7.3, and this is reflected in the implementation.
   
   ### Where this lives in the code today
   
   #### `atr/models/sql.py` — `LifecycleEventType` (lines 262-268)
   _currently does this_
   The enum defines all six event types specified in the issue (release, 
archive, withdraw, eod, eos, eol).
   
   ```python
   class LifecycleEventType(enum.StrEnum):
       RELEASE = "release"
       ARCHIVE = "archive"
       WITHDRAW = "withdraw"
       EOD = "eod"
       EOS = "eos"
       EOL = "eol"
   ```
   
   #### `migrations/versions/0076_2026.05.06_e5fa9b30.py` — `upgrade` (lines 
39-54)
   _currently does this_
   The migration creates the lifecycleevent table with all fields specified in 
the issue plus foreign keys and the three search indexes (project_event, 
cycle_event, version_event).
   
   ```python
   def upgrade() -> None:
       op.create_table(
           "lifecycleevent",
           sa.Column("id", sa.Integer(), nullable=False),
           sa.Column("project_key", sa.String(), nullable=False),
           sa.Column("cycle_key", sa.String(), nullable=True),
           sa.Column("version_key", sa.String(), nullable=True),
           sa.Column(
               "event",
               sa.Enum("RELEASE", "ARCHIVE", "WITHDRAW", "EOD", "EOS", "EOL", 
name="lifecycleeventtype"),
               nullable=False,
           ),
           sa.Column("effective", sql.UTCDateTime(timezone=True), 
nullable=False),
           sa.Column("published", sql.UTCDateTime(timezone=True), 
nullable=False),
           sa.Column("target_event_id", sa.Integer(), nullable=True),
           sa.Column("reference_urls", sa.JSON(), nullable=False),
   ```
   
   #### `atr/cle.py` — `project_document` (lines 62-75)
   _currently does this_
   The CLE document generator reads from LifecycleEvent rows and renders to 
ECMA-428 wire format, demonstrating the model is fully in use.
   
   ```python
   def project_document(
       project: sql.Project,
       events: Iterable[sql.LifecycleEvent],
       releases: Iterable[sql.Release],
       *,
       now: datetime.datetime,
   ) -> dict[str, Any]:
       """Generate a CLE document covering every event for a project.
   
       This is the canonical form per ECMA-428: one document per component.
       `releases` are needed to resolve version strings and cycle release sets
       at render time.
       """
       return _document(project, list(events), list(releases), now=now)
   ```
   
   #### `tests/unit/test_cle.py` — 
`test_render_event_release_emits_version_and_separate_dates` (lines 58-73)
   _currently does this_
   Comprehensive test coverage exists for the CLE rendering of lifecycle events.
   
   ```python
   def test_render_event_release_emits_version_and_separate_dates():
       project = SimpleNamespace(key="foo", 
version_method=sql.VersionMethod.SIMPLE)
       rel = SimpleNamespace(version="1.2.3", key="foo-1.2.3", 
cycle_key="foo-default")
       event = _event(
           event=sql.LifecycleEventType.RELEASE,
           effective=datetime.datetime(2026, 1, 1, tzinfo=datetime.UTC),
           published=datetime.datetime(2025, 12, 1, tzinfo=datetime.UTC),
           version_key="foo-1.2.3",
           cycle_key="foo-default",
       )
       rendered = cle._render_event(project, event, {"foo-1.2.3": rel}, 
{"foo-default": [rel]})
       assert rendered["type"] == "released"
       assert rendered["effective"] == "2026-01-01T00:00:00Z"
       assert rendered["published"] == "2025-12-01T00:00:00Z"
       assert rendered["version"] == "1.2.3"
       assert rendered["license"] == "Apache-2.0"
   ```
   
   ### Proposed approach
   The lifecycle event model described in this issue has been fully 
implemented. The database schema (migration 0076), the LifecycleEventType enum 
in atr/models/sql.py, the ECMA-428 CLE document generator in atr/cle.py, and 
unit tests in tests/unit/test_cle.py all exist and match the requirements 
specified in the issue. The discussion about 'end of support' terminology was 
resolved by @sbp citing the ECMA-428 § 7.3 narrow definition, and @dave2wave 
concurred by changing eom to eos. This is reflected in the implementation. No 
further code changes are needed; the issue can be closed as completed.
   
   ### Open questions
   - The LifecycleEvent SQLModel class definition is likely in the truncated 
portion of atr/models/sql.py - cannot verify its exact field definitions match 
the migration.
   - Whether a lifecycle_event() query builder method exists in 
atr/db/__init__.py (file was truncated) for the three search patterns described 
in the issue.
   - Whether storage writers or API endpoints exist for creating lifecycle 
events (not visible in provided files).
   
   ### Staleness assessment
   
   _opened 50 days ago; last human comment 3 days ago._
   
   Last human activity was 3 days ago (2026-05-05). The implementation 
(migration dated 2026-05-06) was created after the last discussion comment. The 
issue is actively being worked on and appears to have been completed very 
recently.
   
   **Recommendation: consider closing this issue.** If the maintainer agrees, 
the agent's assessment above provides the rationale to include in a closing 
comment.
   
   _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
   - `atr/cle.py`
   - `migrations/versions/0076_2026.05.06_e5fa9b30.py`
   - `atr/models/sql.py`
   - `tests/unit/test_cle.py`
   - `atr/db/__init__.py`
   - `atr/db/interaction.py`
   - `atr/storage/__init__.py`
   - `atr/storage/writers/release.py`
   
   ### Related issues
   This issue appears related to: #912.
   
   _Both define project cycle and lifecycle event models for tracking release 
information_
   
   ---
   *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]

Reply via email to