Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI] action triggered by push is displayed under PR #25736

Closed
harryzcy opened this issue Jul 7, 2023 · 5 comments · Fixed by #25746
Closed

[CI] action triggered by push is displayed under PR #25736

harryzcy opened this issue Jul 7, 2023 · 5 comments · Fixed by #25746
Labels
topic/gitea-actions related to the actions of Gitea type/bug
Milestone

Comments

@harryzcy
Copy link
Contributor

harryzcy commented Jul 7, 2023

Description

When a PR is merged, the action should be trigged by push event. But on Gitea UI, it's showing under PR commit. The issue is introduced in v1.19.4.

Gitea Version

v1.19.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

This shows the actions is triggered by push and is associated with commit.

image

However, on the main branch, the action doesn't show up.

image

Under the already merged PR's last commit, the action is showing.

image

Git Version

No response

Operating System

No response

How are you running Gitea?

Run in Kubernetes.

Database

PostgreSQL

@Zettat123 Zettat123 added the topic/gitea-actions related to the actions of Gitea label Jul 7, 2023
@wolfogre
Copy link
Member

wolfogre commented Jul 7, 2023

Could you please show us your workflow file?

@harryzcy
Copy link
Contributor Author

harryzcy commented Jul 7, 2023

@wolfogre

Edit: well, after posting this, I realized the workflow is expected not to run on push to main branch (with tags-ignore and no included branches). That's an error on me.

But should merging PR trigger an event at all? Is that expected to trigger another pull_request event?

name: Tests

on:
  push:
    tags-ignore:
      - "v*"
  pull_request:
    branches: [main]

jobs:
  python-test:
    name: Python Tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: https://github.com/actions/checkout@v3

      # - name: Set up Python
      #   uses: https://github.com/actions/setup-python@v4
      #   with:
      #     python-version: "3.11"
      - name: Set up Python
        run: |
          VERSION=3.11.4
          cd /tmp/
          wget -q https://www.python.org/ftp/python/$VERSION/Python-$VERSION.tgz
          tar -xzvf Python-$VERSION.tgz > /dev/null
          cd Python-$VERSION/

          apt-get update > /dev/null
          apt-get install -y build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev > /dev/null

          ./configure --enable-optimizations > /dev/null
          make -j `nproc` > /dev/null
          make altinstall > /dev/null
          python3.11 -V

          ln -s /usr/local/bin/python3.11 /usr/local/bin/python
          ln -s /usr/local/bin/pip3.11 /usr/local/bin/pip

          python -VV

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pytest pytest-cov ruff
          pip install -r requirements.txt

      - name: Test with pytest
        run: |
          pytest --cov --cov-report=term-missing

@Zettat123
Copy link
Contributor

The first line of job log should show the trigger event. Could you please check the log and show us the trigger event?

image

@harryzcy
Copy link
Contributor Author

harryzcy commented Jul 7, 2023

@Zettat123 For your question, it's triggered by pull_request.
image

Now with the following workflow, two action gets triggered by merging the pull request.

name: Tests

on:
  push:
    tags-ignore:
      - "v*"
    branches:
      - main
  pull_request:
    branches: [main]
image

The one on a detached commit is triggered by pull_request.
image

The one on main is triggered by push.
image

@Zettat123
Copy link
Contributor

#24048 didn't match the activity type of pull_request event correctly. #25746 will fix the bug.

silverwind pushed a commit that referenced this issue Jul 7, 2023
Fix #25736 
Caused by #24048

Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
  pull_request:
    branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.

Co-authored-by: Giteabot <[email protected]>
Zettat123 added a commit to Zettat123/gitea that referenced this issue Jul 10, 2023
Fix go-gitea#25736
Caused by go-gitea#24048

Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
  pull_request:
    branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.

Co-authored-by: Giteabot <[email protected]>
Zettat123 added a commit to Zettat123/gitea that referenced this issue Jul 10, 2023
Fix go-gitea#25736
Caused by go-gitea#24048

Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
  pull_request:
    branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.

Co-authored-by: Giteabot <[email protected]>
silverwind pushed a commit that referenced this issue Jul 10, 2023
Backport #25746

Fix #25736
Caused by #24048

Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
  pull_request:
    branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.

Co-authored-by: Giteabot <[email protected]>
lunny pushed a commit that referenced this issue Jul 11, 2023
Backport #25746

Fix #25736
Caused by #24048

Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
  pull_request:
    branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.
Codeberg-org pushed a commit to Codeberg-org/gitea that referenced this issue Jul 12, 2023
…o-gitea#25797)

Backport go-gitea#25746

Fix go-gitea#25736
Caused by go-gitea#24048

Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
  pull_request:
    branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.

Co-authored-by: Giteabot <[email protected]>
(cherry picked from commit bd1946e)
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
topic/gitea-actions related to the actions of Gitea type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants