Skip to content

Updated agit doc for git-repo #27014

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

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions docs/content/usage/agit-support.en-us.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,3 +47,26 @@ Here's another advanced example for creating a new PR targeting `master` with `t
```shell
git push origin HEAD:refs/for/master -o topic="Topic of my PR" -o title="Title of the PR" -o description="# The PR Description\nThis can be **any** markdown content.\n- [x] Ok"
```

## Using `git-repo`

If you want to use [`git-repo`](https://git-repo.info/) for your agit workflow, either in single- or multi-repo mode, you need to take a few steps.

1. Create a file in `$GITEA_CUSTOM/public/` called `ssh_info`
2. Populate it with `{"type":"agit","version":2}`
3. Add a rewrite rule for your reverse proxy which rewrites the request path equaling `/ssh_info` to `/assets/ssh_info`
Copy link
Member

@silverwind silverwind Sep 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we already provide a mechanism to put files into root, like /robots.txt? Or maybe that path is already occupied, not familiar with /ssh_info.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only one I could find was /assets/<file>, and repo/git-repo expect it to be at the root of the host 🤷🏼‍♀️

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The quite old "assets" handler logic is: if local file exists, then use it, otherwise, pass it to other handles.

However, the logic has been changed long time ago, the local file doesn't have higher priority than other handlers.

For example: if you have a file in {Custom}/public/my-name and an org my-name

  • For quite old logic (very long time ago): the local file {Custom}/public/my-name is served
    • Users could serve any custom files without reverse proxy tweaks.
  • For current logic (has been changed long time ago): the org my-name is severed.

TBH, the quite old logic looks good to me, while I guess some nice features were changed unintentionally by many round iterations.

Copy link
Contributor

@wxiaoguang wxiaoguang Sep 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change was introduced by : "add /assets as root dir of public files #15219" and "Customization files should not require /assets path segment #15906" in 1.15

After that PR, users couldn't serve their custom files in web root anymore.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is special handling for robots.txt to remain under the root path. Maybe we could include the ssh_info in the binary directly? It would require reserving the "ssh_info" username, but I think that would be acceptable as a "breaking" change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to take the "quite old logic" back, then end users could still have the ability to serve any file in the web root.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, gitea has defined /ssh_info router, but the type has been defined as gitea (example: https://try.gitea.io/ssh_info), That's because I'm not sure agit flow has been fully implement. looks need more work. and I hasn't checking whether gitea can be used with git-repo tool also.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whether gitea can be used with git-repo tool also.

I'm working through why it hasn't been working as intended, and this is what I've found so far. If the router has implemented /ssh_info but it's wrong, then we should fix it. It's ultimately something from Gerrit:

https://github.com/GerritCodeReview/gerrit/blob/587e12178e06e63c0ac8c31e6ec0cbc59b232eea/java/com/google/gerrit/httpd/raw/SshInfoServlet.java#L31-L48

4. Restart Gitea
5. Within a project in your `git-repo` workspace, run `git pr -vv`

If the reverse proxy rewrite has been implemented correctly, you should see something like this:

```sh
$ git pr -vv
DEBUG: get ssh_info from API: https://$ROOT_URL/ssh_info
DEBUG: fail to get proxy from git config: http.proxy is not set
DEBUG: query ssh_info successfully: &helper.SSHInfo{PushURL:"", Host:"", Port:0, User:"", ProtoType:"agit", ProtoVersion:2, ReviewRefPattern:"", Expire:0}
DEBUG: save cache file '~/workspace/.repo/projects/manifest.git/info/sshinfo.cache', expire at '2023-09-11 14:48:11', data: '{"type":"agit","version":2}'
NOTE: no branches ready for upload
```

`git-repo` has been correctly configured for Gitea.