migrate urfave/cli to v2 version

[6543]

as title

references:

• Create a v1 => v2 migration guide urfave/cli#921
• https://github.com/urfave/cli/releases/tag/v2.0.0

[lunny]

CI failed seems related.

[6543]

Yes .. still same problem

(Internal binary exec call behave diffenent)

[wxiaoguang]

IIRC, this PR is blocked by the different behavior for argument orders between urfave/cli v1 and v2 ?

https://github.com/urfave/cli/blob/main/docs/migrate-v1-to-v2.md#flags-before-args

It has been a long time, if it is the case, then there might be 2 choices:

1. Introducing the breaking into Gitea for next release
2. Keep urfave/cli.v1 , never go to v2

Correct me if I am wrong .....

[lunny]

It depends on how much benefit for Gitea migrate to v2.

[wxiaoguang]

The design of urfave/cli.v2 is overall better than v1, except the flags must be before args rule. I can not understand why the cli author made such a strict rule (is there any way to bypass?)

[lunny]

How about my suggestion in #10912 (comment)

[jolheiser]

The design of urfave/cli.v2 is overall better than v1, except the flags must be before args rule. I can not understand why the cli author made such a strict rule (is there any way to bypass?)

POSIX-compliance is the quoted reason, and my guess is it makes parsing much less complex.

---

I am personally not a fan of cobra, so that's a 👎 from me. Many projects use it successfully, but I don't personally like it compared to urfave.

[6543]

I'm for change how internal git command create arguments - this will be breaking but should be fine if git hooks are recreated

[wxiaoguang]

I'm for change how internal git command create arguments - this will be breaking but should be fine if git hooks are recreated

We can write a migration task to delete the Gitea binary path in AppState table, then Gitea will re-create all hooks automatically.

---

However, there are many scripts using Gitea binary, such change would break all a lot of them ..... I am still worrying about the breaking is too large. Maybe we should write a detailed document to evaluate the risk before spending coding time on it.

[zeripath]

I presume that this args change doesn't mean that even subcommand args have to be before the subcommand?

If so looking at our docs we say:

gitea [global options] command [command or global options] [arguments...]

So whilst it's a breaking change it's more an undocumented change.

[wxiaoguang]

-> Refactor to use urfave/cli/v2 #25959