The Wayback Machine - https://web.archive.org/web/20220108201851/https://github.com/go-gitea/gitea/pull/17185
Skip to content
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

Raw file API: deprecate {ref} path parameter + allow shortened commit refs #17185

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

@noerw
Copy link
Member

@noerw noerw commented Sep 29, 2021

Looking into #17179 I noticed a couple oddities with the raw file API:

  • it supports an undocumented path parameter to specify the ref ({repo_api_url}/raw/{ref}/{tree_path}).
    Parsing this is a mess, see context/repo.go getRefName()
  • due to lacking docs, a new query param ?ref= was added in #14602, now providing a duplicate parameter (and a deprecation path! 😄)
  • #13686 brought support for abbreviated commit SHAs, but omitted support for that in the API route, I'm not sure why (@lafriks?)

All this culminates in the weird failure mode of #17179.

This PR aims to fix #17179, but also to find a way out of this mess:

  • adds support for short commit SHAs on the old {ref} path parameter, to fix above bug
  • documents the old path parameter {ref}
  • deprecates the old path parameter

Backporting the actual bugfix is simpler, as mentioned in df834a7

noerw added 4 commits Sep 29, 2021
the ?ref= param was added recently in go-gitea#14602, and can fully replace the
(previously undocumented) ref-prefix of the filepath
we just deprecated this API, but this is a short fix to go-gitea#17179
A more minimal fix would be to check
  if len(parts) > 1
in line context/repo.go#L698
@@ -413,7 +413,7 @@ func RepoRefForAPI(next http.Handler) http.Handler {
return
}
ctx.Repo.CommitID = ctx.Repo.Commit.ID.String()
} else if len(refName) == 40 {
} else if len(refName) >= 7 && len(refName) <= 40 {
Copy link
Contributor

@delvh delvh Sep 29, 2021

Choose a reason for hiding this comment

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

I doubt that that will improve the situation.
"Great. Now I cannot even get the README.md".
Maybe it would be better to check whether that file is tracked when the if three lines below is entered before returning the error.

Or do I misunderstand what this is supposed to do?
Regarding the else block below, I am fairly certain that I am misunderstanding something here.

Copy link
Contributor

@wxiaoguang wxiaoguang Sep 30, 2021

Choose a reason for hiding this comment

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

I don't think hard-coding the length is a good idea. Maybe git will use SHA256 in future.

https://stackoverflow.com/questions/28159071/why-doesnt-git-use-more-modern-sha

Copy link
Member Author

@noerw noerw Sep 30, 2021

Choose a reason for hiding this comment

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

@delvh no this won't happen, as we check if such a commit exists. If not, getRefName() falls back to treating the entire thing as a TreePath and returns Repo.DefaultBranch as ref, in which case we don't enter this if-clause at all.
@wxiaoguang this is all over the codebase, definitily a different issue.

Copy link
Contributor

@wxiaoguang wxiaoguang Sep 30, 2021

Choose a reason for hiding this comment

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

Maybe we can introduce a function like IsPossibleGitCommit and use it from now on. It's easier to understand and maintain.

@lunny
Copy link
Member

@lunny lunny commented Sep 30, 2021

Maybe we should have a break change.{repo_api_url}/raw/{ref}/{tree_path} is the only router and drop {repo_api_url}/raw/{tree_path}.

@lafriks
Copy link
Member

@lafriks lafriks commented Sep 30, 2021

Answering to your question shortened commit sha was added because of support needed for pkg.go.dev

As for API I did not see need for it as for API you will usually work with full commit sha

As for legacy urls we should drop support for them imho, it's been quite some time already

@noerw
Copy link
Member Author

@noerw noerw commented Sep 30, 2021

Maybe we should have a break change. {repo_api_url}/raw/{ref}/{tree_path} is the only router and drop {repo_api_url}/raw/{tree_path}.

@lunny Aesthetically I too prefer the {ref} path parameter, but

  1. this was never documented, so removing (or better deprecating, I'd bet there are users of this) this one and keeping the ?ref= variant is not a breaking change
  2. this is a pain to parse, specifying ref in a separate query param simplifies the code a lot
  3. (using ?ref= is also closer to GH API, though they have changed their raw file handling a couple times over, so compatibility isn't given anyway)

@noerw
Copy link
Member Author

@noerw noerw commented Sep 30, 2021

regarding the CI fail in check:

310See errors below:
311- "paths./repos/{owner}/{repo}/raw/{ref}/{filepath}.get.parameters" must validate one and only one schema (oneOf). Found none valid
313- in operation "repoGetRawFileOld",path param "ref" must be declared as required

well.. the ref param isn't required. is there a workaround wrt the linter? (It dawns upon me that this is the reason this param was never documented..)

noerw added a commit to noerw/gitea that referenced this issue Oct 8, 2021
...when path contains no hash-path-separator ('/')

This is a workaround to go-gitea#17179.

Entering this case when `path` does not contain a '/' does not really
make sense, as that means the tree path is empty, but this case is only
entered for routes that expect a non-empty tree path.

Treepaths like <40-char-dirname>/<filename> will still fail,
but hopefully don't occur that often. A more complete fix that avoids
this case too is outlined in go-gitea#17185, but too big of a change to backport
techknowlogick pushed a commit that referenced this issue Oct 8, 2021
...when path contains no hash-path-separator ('/')

This is a workaround to #17179.

Entering this case when `path` does not contain a '/' does not really
make sense, as that means the tree path is empty, but this case is only
entered for routes that expect a non-empty tree path.

Treepaths like <40-char-dirname>/<filename> will still fail,
but hopefully don't occur that often. A more complete fix that avoids
this case too is outlined in #17185, but too big of a change to backport
@lunny lunny added this to the 1.16.0 milestone Oct 30, 2021
@lunny
Copy link
Member

@lunny lunny commented Nov 19, 2021

Please resolve the conflicts.

@techknowlogick techknowlogick removed this from the 1.16.0 milestone Nov 23, 2021
@techknowlogick techknowlogick added this to the 1.17.0 milestone Nov 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment