ilia/punimtag
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

chore: Update CI workflow to trigger only on pull_request events
Some checks failed
CI / skip-ci-check (pull_request) Successful in 1m29s
Details
CI / lint-and-type-check (pull_request) Successful in 2m6s
Details
CI / python-lint (pull_request) Successful in 1m55s
Details
CI / test-backend (pull_request) Successful in 3m10s
Details
CI / build (pull_request) Successful in 2m26s
Details
CI / secret-scanning (pull_request) Successful in 1m42s
Details
CI / dependency-scan (pull_request) Successful in 1m35s
Details
CI / workflow-summary (pull_request) Has been cancelled
Details
CI / sast-scan (pull_request) Has been cancelled
Details

Browse Source 
This commit modifies the CI workflow to exclusively trigger on pull_request events, preventing duplicate runs caused by push events. It clarifies comments regarding event handling and emphasizes the importance of using pull requests for CI, enhancing the overall clarity and efficiency of the workflow.
This commit is contained in:
Tanya 2026-01-08 13:24:41 -05:00
parent 45ceedc250
commit bd3fb5ce74
1 changed files with 10 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
.gitea/workflows/ci.yml
View File

@ -2,15 +2,15 @@
name: CI
on:
# Trigger on push for protected branches (master, dev) - direct pushes only
# Trigger on pull_request for all branches - PRs to master/dev and feature branches
# This separation prevents duplicate runs: pushes to master/dev don't conflict with PRs
push:
branches: [master, dev]
# Only trigger on pull_request events to avoid duplicate runs
# Push events to dev/master are disabled because they conflict with PR events
# PR events provide better context and eliminate duplicate workflow runs
# If you need CI on direct pushes (without PR), you can re-enable push events
# but be aware that duplicate runs may occur when both push and PR events fire
pull_request:
types: [opened, synchronize, reopened]
# PRs can target any branch, but we only test PRs targeting master/dev
# Feature branch PRs will also trigger, but they won't conflict with push events
# PRs targeting any branch will trigger CI
# This includes PRs to master/dev and feature branch PRs
# Prevent duplicate runs when pushing to a branch with an open PR
# This ensures only one workflow runs at a time for the same commit
@ -56,18 +56,9 @@ jobs:
SKIP=0
# Skip push events if this is a push (not a PR) to avoid duplicates with PR events
# PR events are preferred as they provide better context
if [ -z "$GITHUB_EVENT_PULL_REQUEST_NUMBER" ] && [ "$GITHUB_EVENT_NAME" = "push" ]; then
# For push events, only run on master/dev branches (protected branches)
# Feature branches should use PR events only
if [ "$BRANCH_NAME" != "master" ] && [ "$BRANCH_NAME" != "dev" ]; then
echo "Skipping CI: Push event on feature branch '$BRANCH_NAME' (use PR events instead)"
SKIP=1
fi
# Note: For dev/master, we rely on concurrency group to prevent duplicates
# If both push and PR events fire, concurrency will cancel one
fi
# Note: Push events are disabled in workflow triggers to prevent duplicates
# Only pull_request events trigger this workflow now
# If push events are re-enabled, add skip logic here to prevent duplicates
# Check branch name (case-insensitive)
if [ $SKIP -eq 0 ] && echo "$BRANCH_NAME" | grep -qiF "$SKIP_PATTERN"; then