Autonomous agents must run tests before pushing. Pattern:
Layer 1 (unit): make test — pure logic, <1s
Layer 2 (integration): make test-sqlite — real DB, real handlers
Layer 3 (E2E): npx playwright test — browser tests
tinqs-git already has upstream Gitea test infra (better than ariki-game).
Gap: agents don't run them. This handoff fixes that.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Always overwrites S3 on every preview request — no stale content.
Removed sync.Map cache and background goroutines.
Blob-by-SHA paths still skip upload if already exists (immutable).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Fullscreen button added to Preview/Source button group (not overlay)
- iframe breaks out of container: width:100vw with negative margins
- removed overlay expand icon — redundant with header button
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Test page for the S3-backed HTML preview. Demonstrates the feature
it describes — dark theme, Tinqs branding, inline CSS, no relative
image paths.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- height: calc(100vh - 220px) instead of fixed 600px — fills remaining
viewport with no dead space at bottom
- expand button (screen-full icon) in top-right corner opens the S3
presigned URL in a new tab for full-screen viewing
- security preserved: new tab opens S3 origin, not Gitea
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
HTML files now render in an iframe served from S3 (tinqs-git-preview
bucket) instead of Gitea's raw endpoint which forces text/plain.
SWR flow: first request uploads blob to S3 synchronously, subsequent
requests redirect to presigned S3 URL instantly. When the blob SHA
changes (new commit), the stale version is served immediately while
the new version uploads in the background.
Security: iframe uses sandbox="allow-scripts" only (no allow-same-origin).
S3 is a different origin from git.arikigame.com, so even if JS runs in
the iframe it cannot access Gitea session cookies or API tokens.
Config: [html_preview] section in app.ini, disabled by default.
Release pipeline auto-adds config on first deploy.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Backport of #37403 to `release/v1.26`.
The `events › logout propagation` e2e test was racing the SSE connection
setup: if page2's SharedWorker had not finished registering its
messenger by the time page1 triggered logout, the event was silently
dropped and page2 stayed on the authenticated page.
Wait 500ms after verifying page2 is signed in, before triggering the
logout from page1, so the SharedWorker has time to register. Comment
points at a cleaner future fix (expose a ready attribute on the page)
that will also work for the planned WebSocket SharedWorker.
---
This PR was written with the help of Claude Opus 4.7
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>
Backport #37388 by @wxiaoguang
Fix#27120
By the way, refactor ReserveLineBreakForTextarea to NormalizeStringEOL
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #37365 by @pisarz77
Fix team members missing from assignee list when `team_unit.access_mode`
is 0 but the doer is owner.
Fix #34871
1. Use `GetTeamUserIDsWithAccessToAnyRepoUnit` for repo assignee list
2. Load assignee list for project issues directly
3. Use `GetTeamUserIDsWithAccessToAnyRepoUnit` for repo reviewer list
Signed-off-by: Jakub Pisarczyk <pisarz77@gmail.com>
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: pisarz77 <pisarz77@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>
Backport #37288 by @KalashThakare
## Summary
Fixes#37252
The `/api/v1/repos/{owner}/{repo}/actions/runs` endpoint was returning
`event: "push"` for workflow runs triggered by `schedule:` (cron),
instead
of `event: "schedule"`.
## Root Cause
`ActionRun` has two separate fields:
- `Event` — the workflow registration event (e.g. `push`, set when the
workflow file was first pushed)
- `TriggerEvent` — the actual event that triggered the run (e.g.
`schedule`)
`ToActionWorkflowRun` in `services/convert/action.go` was serializing
`run.Event` into the API response instead of `run.TriggerEvent`, causing
scheduled runs to be indistinguishable from push events via the API.
This was already asymmetric — the tasks/jobs API correctly used
`TriggerEvent`.
## Fix
Changed `ToActionWorkflowRun` to use `run.TriggerEvent` for the `event`
field in the API response, consistent with how the jobs API works.
## Before
`event: "push"` returned for all scheduled runs:
<img width="1112" height="191" alt="Screenshot 2026-04-19 115642"
src="https://github.com/user-attachments/assets/c0a169f5-bbd9-4f5d-9474-e4c3795110e4"
/>
## After
`event: "schedule"` correctly returned for scheduled runs:
<img width="890" height="166" alt="Screenshot 2026-04-19 121723"
src="https://github.com/user-attachments/assets/860e99ac-0935-4a43-86a1-7b60f8113480"
/>
## Testing
- Added unit test `TestToActionWorkflowRun_UsesTriggerEvent` in
`services/convert/action_test.go` that explicitly verifies the API
returns `TriggerEvent` and not `Event` for a scheduled run.
- Manually verified via the API against a live Gitea instance with a
`cron: "* * * * *"` workflow.
Co-authored-by: Kalash Thakare ☯︎ <kalashthakare898@gmail.com>
Co-authored-by: Nicolas <bircni@icloud.com>
Backport #37324 by @lunny
A quick fix#37317
---
The current behavior for forks when an organization or repository is
changed to private differs from GitHub.
On GitHub, when a parent repository becomes private, the fork
relationship is removed, which keeps the behavior simple and avoids
visibility conflicts.
I think we need a similar solution to handle cases where the parent
repository becomes private while a fork remains public and the fork
relationship is still preserved.
Signed-off-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
ozan
Lunny Xiao