Skip to content

[BUG] In 1.15.0, git push activites does not work, webhook on push not work #16428

@duchenpaul

Description

@duchenpaul
  • Gitea version (or commit ref): 1.15.0+dev-578-g8464fa15d
  • Git version:
  • Operating system: official docker
  • Database (use [x]):
    • PostgreSQL
      MySQL
      MSSQL
      SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (You edit a file commit it, this behavior will not show up in the dashboard, and if you have webhook, it will not trigger)
      No
  • Log gist:
    Sorry, but I dont see any error/abnormals in logs of gitea.

Description

I upgraded my gitea image to the latest version in dockerhub.
And the webhook no longer works, I found that my git push activities are not presenting in my dashboard.
Looks like the new version gitea totally missed my git push activities.

Action
You push a commit to a repo.

Expected

  • Your commit shows up in the dashboard, like below,
    image

  • The webhook of this repo will be triggered by this push

Actual

  • You can see your commit in the source code page
  • But your commit does not show up in the dashboard
  • The webhook is not triggered

Below is my recordings about that, all I test is to push a commit into the repo, and expect this action to be shown in the dashboad, and demostrate that it works in the older version, and not working in the newest one

Screenshots

good
Git activities works in v1.14.4

bad
Git activities breaks in v1.15.0

Activity

zeripath

zeripath commented on Jul 14, 2021

@zeripath
Contributor

I'm likely being completely dense but I can't for the life of me understand what it is that is not happening when it should and what it is that you're trying to do.

The videos are not that helpful by themselves. Please describe what it is you are doing.

changed the title [-]In 1.15.0, git push activites does not work, webhoot on push not work[/-] [+][BUG] In 1.15.0, git push activites does not work, webhoot on push not work[/+] on Jul 14, 2021
duchenpaul

duchenpaul commented on Jul 14, 2021

@duchenpaul
Author

I'm likely being completely dense but I can't for the life of me understand what it is that is not happening when it should and what it is that you're trying to do.

The videos are not that helpful by themselves. Please describe what it is you are doing.

Sorry for the inconvinience, I expanded more details about the issue, if you have any questions, please let me know

lunny

lunny commented on Jul 14, 2021

@lunny
Member

I cannot reproduce this on my local macOS Gitea instance.

zeripath

zeripath commented on Jul 14, 2021

@zeripath
Contributor

I suspect that you need to resynchronize the hooks.

Also ensure that your repositories are not being mounted as noexec

zeripath

zeripath commented on Jul 14, 2021

@zeripath
Contributor

Your browser is obscuring the most important part of the logs too. When you make the push there should be a call to:

api/internal/hook/pre-receive/:owner/:repo and api/internal/hook/post-receive/:owner/:repo

if that's not there then it's clear that your hooks aren't either being run or are being sent to the wrong place.

duchenpaul

duchenpaul commented on Jul 15, 2021

@duchenpaul
Author

Take a step back, on https://try.gitea.io,
when you push a change, there should be an update to the dashboard, saying :username pushed to :branch_name at :repo_name, like so:
image

I just tried to do so in https://try.gitea.io, there is no such update on my dashboard.
The url is here: https://try.gitea.io/duchenpaul/Hosted

You can see the last commit is Thu, 15 Jul 2021 00:17:11 UTC
image

if you go to my profile, the last update is Wed, 14 Jul 2021 15:52:44 UTC, which the time when the repo was forks, not get updated by my push.
image

duchenpaul

duchenpaul commented on Jul 15, 2021

@duchenpaul
Author

In order to reproduce, please:

  • create/fork a repo in https://try.gitea.io/
  • Push a commit
  • if you have a webhook, check its Recent Deliveries to see if it is triggered
multicast

multicast commented on Jul 15, 2021

@multicast

I can confirm; I have the same behavior in 1.15.0+dev-582-g3dcb3e907

Creating a new repository via UI, copy/paste initial commands and pushing README to master, and UI never shows code, but the introductory message. I veriefied that the data are actually pushed and the bare repository has the "first commit" pushed, but web-UI still displays hint on how to add origin or make first commit.

duchenpaul

duchenpaul commented on Jul 15, 2021

@duchenpaul
Author

@multicast yeah, if you use webhook, it won't trigger

multicast

multicast commented on Jul 15, 2021

@multicast

@duchenpaul no, create repo, git init/touch/add...push, and the repo on the web looks like no push happened. but repositories/user/name.git does contain the commit. there is no special webhook added yet to newly created repo yet.

Xenolphthalein

Xenolphthalein commented on Jul 15, 2021

@Xenolphthalein

I can reproduce this issue with a newly created docker instance on 1.15.0 (latest).

  • Create a docker container with 1.15.0 (latest)
  • Go through the basic configuration
  • Configure your ssh key
  • Create a new repository
  • Push to that repository via ssh
  • Find that the repository still shows the Setup Guide in the Web GUI
  • Cloning the repository from the remote to another folder works as expected

If you revert to 1.14.4 everything works as expected.

multicast

multicast commented on Jul 15, 2021

@multicast

I was now on the same journey and confirm :latest tag is buggy and :1.14.4 works.

The database version has been bumped since 1.14.4 several times, what issues I can expect when looking at models/migrations/v178 ... 188.go?

changed the title [-][BUG] In 1.15.0, git push activites does not work, webhoot on push not work[/-] [+][BUG] In 1.15.0, git push activites does not work, webhook on push not work[/+] on Jul 15, 2021
zeripath

zeripath commented on Jul 15, 2021

@zeripath
Contributor

I can reproduce this issue with a newly created docker instance on 1.15.0 (latest).

  • Create a docker container with 1.15.0 (latest)
  • Go through the basic configuration
  • Configure your ssh key
  • Create a new repository
  • Push to that repository via ssh
  • Find that the repository still shows the Setup Guide in the Web GUI
  • Cloning the repository from the remote to another folder works as expected

If you revert to 1.14.4 everything works as expected.

I just did this and could not reproduce.

8 remaining items

zeripath

zeripath commented on Jul 15, 2021

@zeripath
Contributor

I've just tried the compose route: (docker-compose version 1.29.2, build 5becea4c on 1.15.0+dev-582-g3dcb3e907 and still can't reproduce this.

docker-compose.yml
version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:22"
app.ini
APP_NAME = Gitea: Git with a cup of tea
RUN_MODE = prod
RUN_USER = git

[repository]
ROOT = /data/git/repositories

[repository.local]
LOCAL_COPY_PATH = /data/gitea/tmp/local-repo

[repository.upload]
TEMP_PATH = /data/gitea/uploads

[server]
APP_DATA_PATH    = /data/gitea
DOMAIN           = localhost
SSH_DOMAIN       = localhost
HTTP_PORT        = 3000
ROOT_URL         = http://localhost:3000/
DISABLE_SSH      = false
SSH_PORT         = 2222
SSH_LISTEN_PORT  = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /data/git/lfs
LFS_JWT_SECRET   = xxxx
OFFLINE_MODE     = false

[database]
PATH     = /data/gitea/gitea.db
DB_TYPE  = sqlite3
HOST     = localhost:3306
NAME     = gitea
USER     = root
PASSWD   = 
LOG_SQL  = false
SCHEMA   = 
SSL_MODE = disable
CHARSET  = utf8

[indexer]
ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve

[session]
PROVIDER_CONFIG = /data/gitea/sessions
PROVIDER        = file

[picture]
AVATAR_UPLOAD_PATH            = /data/gitea/avatars
REPOSITORY_AVATAR_UPLOAD_PATH = /data/gitea/repo-avatars
DISABLE_GRAVATAR              = false
ENABLE_FEDERATED_AVATAR       = true

[attachment]
PATH = /data/gitea/attachments

[log]
MODE      = console
LEVEL     = info
ROUTER    = console
ROOT_PATH = /data/gitea/log

[security]
INSTALL_LOCK                  = true
SECRET_KEY                    = xxxx
REVERSE_PROXY_LIMIT           = 1
REVERSE_PROXY_TRUSTED_PROXIES = *
INTERNAL_TOKEN                = xxx
PASSWORD_HASH_ALGO            = pbkdf2

[service]
DISABLE_REGISTRATION              = false
REQUIRE_SIGNIN_VIEW               = false
REGISTER_EMAIL_CONFIRM            = false
ENABLE_NOTIFY_MAIL                = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
ENABLE_CAPTCHA                    = false
DEFAULT_KEEP_EMAIL_PRIVATE        = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING       = true
NO_REPLY_ADDRESS                  = noreply.localhost

[mailer]
ENABLED = false

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true
`docker version`
Client:
 Version:           20.10.2
 API version:       1.41
 Go version:        go1.13.8
 Git commit:        20.10.2-0ubuntu1~20.04.2
 Built:             Tue Mar 30 21:24:57 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.2
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.8
  Git commit:       20.10.2-0ubuntu1~20.04.2
  Built:            Mon Mar 29 19:10:09 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4-0ubuntu1~20.04.2
  GitCommit:        
 runc:
  Version:          1.0.0~rc95-0ubuntu1~20.04.1
  GitCommit:        
 docker-init:
  Version:          0.19.0
  GitCommit:        

I'm really confused as to what is going on here.

zeripath

zeripath commented on Jul 15, 2021

@zeripath
Contributor

But I can see that try.gitea.io isn't working! For both http and ssh pushing.

techknowlogick

techknowlogick commented on Jul 15, 2021

@techknowlogick
Member
This is `docker version` info from try
Client: Docker Engine - Community
 Version:           19.03.11
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        42e35e61f3
 Built:             Mon Jun  1 09:12:41 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.11
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       42e35e61f3
  Built:            Mon Jun  1 09:11:15 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Sooo... this means if we stick with alpine 3.14 then we need to note the minimum version of docker required. Here are minimum requirements: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2

zeripath

zeripath commented on Jul 16, 2021

@zeripath
Contributor

So... it is the alpine 3.14 PR then and it was a capabilities/permissions issue.

I think we probably have to revert the alpine 3.14 PR - and move that to later in 1.16. Then we can deprecate docker 19 this cycle and make the break in 1.16.

techknowlogick

techknowlogick commented on Jul 16, 2021

@techknowlogick
Member

@zeripath yeah :( That's probably the best direction. I'll send the PRs

zeripath

zeripath commented on Jul 16, 2021

@zeripath
Contributor

whilst you're at it you could approve the three PRs I just dropped fixing some of my own earlier stupidity!

techknowlogick

techknowlogick commented on Jul 16, 2021

@techknowlogick
Member

my own earlier stupidity!

I mean, others missed it too, so... but this was an easy thing to miss so I wouldn't beat yourself up over it.

techknowlogick

techknowlogick commented on Jul 16, 2021

@techknowlogick
Member

PR sent. thanks to everyone who reported this issue and for providing detailed follow up information so we could trace where this was happening.

locked and limited conversation to collaborators on Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @lunny@techknowlogick@multicast@zeripath@duchenpaul

      Issue actions

        [BUG] In 1.15.0, git push activites does not work, webhook on push not work · Issue #16428 · go-gitea/gitea