I googled this topic for a few hours now and could not find an answer.
I created an issue (#1)
I made a commit + push with the following comment:
Fixes #1
Closes #1
closes #1
fixes: #1
Fixes: #1
Closes: #1
closes: #1
The issue remained open.
Is it possible to close an issue inserted in Gitea with only a commit + push ?
If so, how ?
Thanks
Not sure which version of Gitea you’re using but I’m on 1.5.x and close by commit message works fine for me:
Could you share your entire commit message? It’s possible there’s something you’re doing that’s not getting parsed or, less likely, that you’re not a collaborator on the repo you’re trying to update.
As I wrote above, the commit message is:
I may or may not be a collaborator. What I know is that
François
I saw you mention the commands and showed you the feature working. But without your full commit message it’s hard to know exactly what happened. For example, it may be that your commit message needs to use those commands on a line following a space after the first line of the commit message, i.e.
fix: it works now, finally
fixes #34
The commit message has eight lines total, which I mentionned above. To wit:
There is nothing else apart those eight lines.
Guessing that threw of the parser. Could you try with something more realistic?
I tried yours:
It does not work either…
I suppose I should go to the original post (reformulated) 
What syntax in a commit message does Gitea expects to close an issue ?
Please amend your commit and match the exact structure of my example above, including space after the first line of the message but with your issue number. Consider trying adding a new issue and close that one too.
See this for more info:
https://help.github.com/articles/closing-issues-using-keywords/
And if none of that works more info is needed about your environment such as logs, guess version and database.
Created Issue #2
Committed + pushed with the following message:
First line of commit message
fixes: #2
This is a three line commit with a blank in the middle.
Issue #2 remains open…
This is Gitea 1.5.2 + PostgreSQL 10.5 + Git 2.18 on CentOS 7.5 (server) and WIndows 10 + GitExtensions / MSYS 64 bits git 2.15 (client)
Well that’s gotta be frustrating. What version of Gitea are you on? Are you able to see anything in the logs? At a minimum, even if the issue remains open, I’d expect to see an update to the issue timeline as I showed earlier in the thread.
If you’re not able to debug you could test on the Gitea test website to know everything works or try out my full stack setup using your version of Gitea to see if you’re able to reproduce there.
For what its worth:
grep UPDATE /var/lib/gitea/log/xorm.log
2018/10/15 14:42:06 [I] [SQL] UPDATE "user" SET "last_login_unix" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{1539607326, 1539607326, 1}
2018/10/15 15:06:56 [I] [SQL] UPDATE "issue_user" SET is_read=$1 WHERE uid=$2 AND issue_id=$3 []interface {}{true, 1, 4}
2018/10/15 15:15:59 [I] [SQL] UPDATE "repository" SET num_issues = num_issues + 1 WHERE id = $1 []interface {}{4}
2018/10/15 15:16:00 [I] [SQL] UPDATE "issue_user" SET is_read=$1 WHERE uid=$2 AND issue_id=$3 []interface {}{true, 1, 5}
grep INSERT /var/lib/gitea/log/xorm.log
2018/10/15 15:15:59 [I] [SQL] INSERT INTO "issue" ("repo_id","index","poster_id","name","content","milestone_id","priority","is_closed","is_pull","num_comments","ref","deadline_unix","created_unix","updated_unix","closed_unix") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15) RETURNING "id" []interface {}{4, 2, 1, "Issue number two", "Second issue", 0, 0, false, false, 0, "", 0, 1539609359, 1539609359, 0}
2018/10/15 15:15:59 [I] [SQL] INSERT INTO "issue_user" ("uid", "issue_id", "is_read", "is_mentioned") VALUES ($1, $2, $3, $4) []interface {}{1, 5, false, false}
2018/10/15 15:15:59 [I] [SQL] INSERT INTO "action" ("user_id","op_type","act_user_id","repo_id","comment_id","is_deleted","ref_name","is_private","content","created_unix") VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10) RETURNING "id" []interface {}{1, 6, 1, 4, 0, false, "", false, "2|Issue number two", 1539609359}
I cannot see anything that hints at an attempt to update an issue
Not sure if the supported databases use stored procedures for that kind of behavior but I’m guessing not given ORM abstraction. Looking at the Gitea repo I see a bug which indicates close by commit has been available for at least a year or so, and I’m guessing you’re on a newer version and testing things out. Why not give my docker rig a spin. I’ve left instructions on how to use it and have had a damn good experience over the last 3 months and 2M+ server requests.
I have added a line to /var/lib/git/<user>/<repo>.git/hooks/{pre-receive, update, post-receive} so as to log wether they are called.
Those are indeed called (one line for each script in my log file)
I even took that one step further, logged the arguments passed to /var/lib/git/<user>/<repo>.git/hooks/update and called it manually:
"/usr/local/bin/gitea" hook --config='/etc/gitea/app.ini' update 'refs/heads/master' '129a1f3d28eea78a3a43154b587fdc1e4762d4aa' '63f5f5bdde45dc52f29222168760c32eb9b5c39c' ; echo $?
Nothing happen in the web UI. Return code is 0 and no message is printed.
I then noticed that the previous issues were not assigned a particular branch, so I created issue #3 inside master then committed + pushed into that same branch. Again, nothing happened.
Sounds like a malfunction. Could you share the Gitea version (or commit SHA) you’re using and specify how long you’ve had your server up and with which database? If the version isn’t in your site footer for you can enable it from app.ini.
IAs I wrote above, the database is PostgreSQL 10.5, and Gitea 1.5.2 (released version).
Yesterday I also tried with 1.5.1 and 1.5.0 (released versions). All three Gitea versions I tried exhibit that issue.
The server had been up for a few minutes in most of the tests (a few hours at most).
Tried to use SQLite instead of PostgreSQL. Specifically:
systemctl stop gitearm /etc/gitea/app.inisystemctl start gitea/var/lib/git/data/gitea.db)/var/lib/git and /var/lib/gitea)localhost but internal LAN-only DNS names)This commit is a fix
fixes: #1
Result: Issue #1 remains open.
Same if I created issue #2 in the master branch.
This is gitea 1.5.2 released version.
You’re welcome to create an account at https://git.habd.as, add some repos and run some further tests. I just bumped to 1.5.2 and the stack is running with postgres.
The whole (sole) point of using Gitea was to have a light-weight DSCM with issue tracking running in-house. If I cannot get that working, I may just as well spend my time setting up something else (fossil is next on my list).
I can’t blame you for wanting to try something else. That’s totally annoying. If Fossil seems like overkill please consider trying out the Docker Compose file from the full stack setup I mentioned earlier I can guarantee what you’re looking to accomplish here will work without issue and tee you up for devops and scale.
I realize this is not supposed to be the place for Fossil vs Gitea comparision but here you go:
Fossil has tickets (issues) and wikis built-in, not as bolt-on features like Git + {Gitea | github | gitlab | gogs}.
Fossil cannot close an issue from a commit either. But at least this is clear from the beginning.
There are significantly less moving parts in Fossil too: same executable, server and client side (acting as an HTTP server in either case) vs server executable (also acting as an HTTP server for Gitea/Gogs) + SSH server + DB engine + client executable (on Windows this requires an additional MSYS2 or Cygwin environment, and possibly Putty) + optional client GUI.
Fossil lacks a functioning GUI for commit / push / pull / clone (Ă la TortoiseXxx or GitExtension on Windows).
One nice thing Fossil shares with Gitea (and Gogs) is the idea of single, small executable and the fact that you can deploy it in-house.
Another data point:
I installed Gitea 1.5.1 on an Ubuntu 18.04 machine. DB in MySQL 5.7.23.
Created a repository via Web UI,
created an issue
committed + pushed a new file with a three lines commit message
Some text for commit
fixes #1
Again issue #1 remained open.