Query: Advanced Search

	Include stories about projects I am a member of.

Better like this indeed, looks good to me.

Looks good to me, thanks !

package.json: Upgrade dependencies

misc: Add banner view to display swh hiring info in an iframe

rlog, cvs2gitdump: Fix handling of revision number greater than one

loader: Use utf-8 instead of ascii to decode rsync output

loader: Ensure to strip trailing slash from origin URL

Fix loading of CVS repositories with non valid UTF-8 paths

add_forge_now: Display pre in request history only for non empty text

In D8086#210308, @vlorentz wrote:

Its syntax is more convenient and it automatically deals with encoding. eg. wtpath = os.path.join(os.fsencode(self.tempdir_path), path) becomes wtpath = self.tempdir_path / path with pathlib

In D8086#210297, @vlorentz wrote:

Have you considered using the opportunity to switch to pathlib?

For the record, we recently disabled any origin URL processing in the Web API part (we were checking an origin URL with and without
trailing slash, but this should only be performed in the Web UI as the Web API should be as dumb as possible, see D7988).

package.json: Upgrade dependencies

api/origin: Do not attempt to lookup similar origin URLs

requirements-test: Ensure pinned mypy version is used with tox

Currently, there is no REST API endpoint to list SourceHut public projects.

browse/content: Fix regression in diff-contents view URL regexp

cvsclient: Retry pserver connection three times in case of failure

cvsclient: Fix pserver error: "protocol error: <path> is not absolute"

cvsclient: Allow to connect to a pserver URL without password

utils: Ensure to return correct revision in parse_external_definition

In D8006#208139, @vlorentz wrote:

wtf...

In D8005#208137, @vlorentz wrote:

Did you check this does not cause issues with other servers?

Remove use of urllib3.util.parse_url and prefer to use urllib.parse.urlparse from standard library instead.

Rebase and centralize similar URLs processing in common/archive.py module.

cypress: Override type command to remove key press delay

cypress/persistent-identifiers: Workaround tests hang issue

On Jenkins , we gain more than one minute in overall cypress tests execution, see build log before that change and build log after that change.

loader: Bump dulwich and remove no longer valid comments

So in the end, the conclusion is that the loader already does the right thing so it's a noop, right?

In D7988#207676, @douardda wrote:

Also, this will "break the API". I am not opposed to this change, but some care should be taken when changing public's API behavior like this. (attempt to check if there are users of the behavior to be modified, document the new behavior, display/return a warning or something, etc)

I think the simplest way to get the pom file associated to a specific release of a maven package is to download it from the folder where we can find the source jar.

In D7980#207569, @douardda wrote:

In D7980#207563, @anlambert wrote:

Ack, I will make the change to the /api/1/origin/ endpoint to remove the URL processing then.

Well that was not he intention of this discussion, this is only about the new graphql API :-)

It make sense to discuss this also for the current API, but it should be a dedicated task; this would change the behavior of the currently published public API, so let's discuss it in a dedicated task.

In D7980#207558, @douardda wrote:

In D7980#207469, @anlambert wrote:

In D7980#207468, @jayeshv wrote:

In D7980#207464, @vlorentz wrote:

Why should this be implemented by the API (as opposed to UIs)?

This is part of our current REST APIs.

which is not a good enough argument to keep it. Let's not reproduce (potential) mistakes, if we can.

I think it makes sense to return
data with or without a slash in both UI and API.

I also agree, extra trailing slash or missing trailing slash in origin URL is a common source of errors when searching for an origin,
better handle that case API side.

I disagree; one expect the API to behave as dumb/simple as possible: you ask for an origin URL, the API should return data on that very specific URL only. Imagine we do have stored both versions of the origin URL (for historical reasons), with and without a trailing /, we want the API to allow the user query one or the other.

If need be, provide an dedicated API endpoint to search for known similar origins, but make it a dedicated one, not part of the main get_origin endpoint.

As @vlorentz suggested, this "smart" behavior is indeed an UI concern, not an API one.

That's better like this indeed, the caught of the base Exception was confusing to me.

assets/readme-rendering: Use showdown github flavor for github origins

Looks good to me. I added some nitpick comments to handle.

Extract origin URL from current browsed one as it is more reliable.

But I don't think adding this logic to that layer (archive layer) is a good idea at least in this case. What
I'm trying to do is to make a utility function to identify all the analogous URLs

In D7980#207468, @jayeshv wrote:

In D7980#207464, @vlorentz wrote:

Why should this be implemented by the API (as opposed to UIs)?

This is part of our current REST APIs. I think it makes sense to return
data with or without a slash in both UI and API.

Advanced Search
Use Results
Edit Query
Hide Query

Jul 12 2022

Jul 11 2022

Jul 8 2022

Jul 7 2022

Jul 6 2022

Jul 1 2022

Jun 30 2022

Jun 21 2022

Jun 20 2022

Jun 17 2022

Jun 16 2022

Jun 15 2022

Jun 14 2022

Jun 13 2022

Advanced SearchUse ResultsEdit QueryHide Query