Skip to content

Integrations.test is erroneously used as the hook in pre-receive.d of a forked repo in integration testing #1910

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.

Sign up for GitHub

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

Jump to bottom
Closed
2 of 7 tasks
typeless opened this issue Jun 8, 2017 · 1 comment · Fixed by #1923
Closed
2 of 7 tasks

Integrations.test is erroneously used as the hook in pre-receive.d of a forked repo in integration testing #1910

typeless opened this issue Jun 8, 2017 · 1 comment · Fixed by #1923
Labels
type/bug type/testing
Milestone
1.2.0

Comments

@typeless
Copy link
Contributor

typeless commented Jun 8, 2017 •
edited
Loading

  • Gitea version (or commit ref):
    v1.1.0-289-g9ddc35e

  • Git version:
    2.7.4

  • Operating system:
    Ubuntu 16.04 64bit

  • Database (use [x]):

    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite

  • Can you reproduce the bug at https://try.gitea.io:

    • Yes (provide example URL)
    • No
    • Not relevant

  • Log gist:

Description

Under the environment created by integrations.test, a forked repo will contain a hook which looks like the following:

cat /tmp/repo1.git/hooks/pre-receive.d/gitea
#!/usr/bin/env bash
"/home/mura/devel/go/src/code.gitea.io/gitea/integrations.test" hook --config='/home/mura/devel/go/src/code.gitea.io/gitea/integrations/sqlite.ini' pre-receive

For some clues I've found so far:
https://github.com/go-gitea/gitea/blob/master/models/repo.go#L946
https://github.com/go-gitea/gitea/blob/master/modules/setting/setting.go#L510
...

P.S. The problem can be reproduced with #1912

Screenshots

If this issue involves the Web Interface, please include a screenshot
@lunny lunny added this to the 1.x.x milestone Jun 8, 2017
@typeless
Copy link
Contributor Author

typeless commented Jun 9, 2017 •
edited
Loading

Any thoughts?

The problem seems to be due to the limitation of the integration framework or the way that the hooks are handled. Neither are obvious to fix to me.

@ethantkoenig ethantkoenig mentioned this issue Jun 9, 2017
Merged
@lunny lunny modified the milestones: 1.2.0, 1.x.x Jul 9, 2017
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
earl-warren pushed a commit to earl-warren/gitea that referenced this issue Dec 10, 2023
@Gusted @earl-warren
[GITEA] Actually recover from a panic in cron task
1f20686 
- Currently there's code to recover gracefully from panics that happen
within the execution of cron tasks. However this recover code wasn't
being run, because `RunWithShutdownContext` also contains code to
recover from any panic and then gracefully shutdown Forgejo. Because
`RunWithShutdownContext` registers that code as last, that would get run
first which in this case is not behavior that we want.
- Move the recover code to inside the function, so that is run first
before `RunWithShutdownContext`'s recover code (which is now a noop).
- Resolves go-gitea#1910
project-mirrors-bot-tu bot pushed a commit to project-mirrors/forgejo-as-gitea-fork that referenced this issue Jan 23, 2025
@Gusted
[GITEA] Actually recover from a panic in cron task
026a4bb 
- Backport go-gitea#1911
- Currently there's code to recover gracefully from panics that happen
within the execution of cron tasks. However this recover code wasn't
being run, because `RunWithShutdownContext` also contains code to
recover from any panic and then gracefully shutdown Forgejo. Because
`RunWithShutdownContext` registers that code as last, that would get run
first which in this case is not behavior that we want.
- Move the recover code to inside the function, so that is run first
before `RunWithShutdownContext`'s recover code (which is now a noop).
- Resolves go-gitea#1910

(cherry picked from commit 761e1c83414407b65e331c2eeb4348c47acf0fbb)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type/bug type/testing
Projects
None yet
Milestone
1.2.0
Development

Successfully merging a pull request may close this issue.

Fix setting.AppPath for integration tests ethantkoenig/gitea
2 participants
@lunny @typeless