audit(codeberg): support codeberg formula

[chenrui333]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

[Bo98]

This PR doesn't do anything at the moment as you need to add code to call it:

brew/Library/Homebrew/formula_auditor.rb

Lines 751 to 772 in ee9766a

	when %r{https?://gitlab\.com/([\w-]+)/([\w-]+)}
	owner = Regexp.last_match(1)
	repo = Regexp.last_match(2)
	tag = SharedAudits.gitlab_tag_from_url(url)
	tag ||= stable.specs[:tag]
	tag ||= stable.version
	if @online
	error = SharedAudits.gitlab_release(owner, repo, tag, formula: formula)
	problem error if error
	end
	when %r{^https://github.com/([\w-]+)/([\w-]+)}
	owner = Regexp.last_match(1)
	repo = Regexp.last_match(2)
	tag = SharedAudits.github_tag_from_url(url)
	tag ||= formula.stable.specs[:tag]
	if @online
	error = SharedAudits.github_release(owner, repo, tag, formula: formula)
	problem error if error
	end

[Bo98]

Suggested change

return if DateTime.parse(release["released_at"]) <= DateTime.now

or published_at but I don't think Codeberg supports future-dated releases.

[chenrui333]

This PR doesn't do anything at the moment as you need to add code to call it:

yeah, let me add those into formula_auditor

[alebcay]

I'd like to contest the notability requirements for Codeberg. As a source code forge, it's not used nearly as much as GitHub/GitLab but the projects may still be consumed a lot by users through other channels, e.g. downstream packagers.

Codeberg lacks much of the social "buzz" that GitHub has (e.g. trending list, personal feed, "awesome" lists) and so discoverability of projects (and the social notion of giving projects "stars") within Codeberg is limited. The concept of stars exist in Codeberg but I think generally people just don't star things they use, either because they never need to go look at the source for it, or they're just not inclined to interact with their source code forge as a social media platform.

Also, some projects have also moved to Codeberg from their prior homes elsewhere, so it's not uncommon that the notability stats don't reflect actual usage or popularity.

[MikeMcQuaid]

@alebcay Can you suggest some alternative values? It doesn't seem reasonable to say there should be no notability requirements on GitHub (or GitLab) but it is reasonable to say these values should vary per platform.

[alebcay]

Here's a look at the stars/forks for some formulae we already have which are currently hosted on Codeberg. I've also included the Repology spread to give some idea of how widely it's packaged downstream, as another metric of adoption/usage, and also our formula stats (30/90/365 days) for formula install/install on request.

Formula	Project	Watchers	Stars	Forks	Repology spread	Formula install (30/90/365 days)	Formula install on request (30/90/365 days)
ipmitool	https://codeberg.org/IPMITool/ipmitool	6	3	7	30	275/1052/2820	275/1049/2807
jdupes	https://codeberg.org/jbruchon/jdupes	2	7	0	20	181/324/634	181/324/634
libid3tag	https://codeberg.org/tenacityteam/libid3tag	6	1	0	43	843/1470/2689	142/228/346
libkeccak	https://codeberg.org/maandree/libkeccak	3	2	0	6	182/564/1258	4/18/63
sha3sum	https://codeberg.org/maandree/sha3sum	3	4	0	5	261/856/1744	262/855/1745
smake	https://codeberg.org/schilytools/schilytools	9	20	10	8	197/268/599	136/168/277
sound-touch	https://codeberg.org/soundtouch/soundtouch	4	15	16	33	23/63/146	23/63/146
star	https://codeberg.org/schilytools/schilytools	9	20	10	10	88/127/196	88/127/196

Notes:

• jdupes moved from GitHub to Codeberg only in the past month or so
• smake/star moved from Sourceforge to Codeberg in the past year or so

Not sure I see any correlation between install counts and star/fork numbers, especially considering e.g. sound-touch or smake/star vs libid3tag.

I would suggest that maybe querying Repology to find a corresponding project there from a given Codeberg repo and having a minimum spread there (e.g. maybe 3 or 5) as a requirement may be more useful.

[MikeMcQuaid]

Not sure I see any correlation between install counts and star/fork numbers, especially considering e.g. sound-touch or smake/star vs libid3tag.

@alebcay Sounds like at least one star would be a sensible requirement and we can drop forks. Thoughts?

[alebcay]

I think that's sufficiently lax, although I will note that it's possible for the project owner to star their own repo (or for the formula submitter to star the repo). So maybe this is not too different from just having no requirement anyways.

[alebcay]

Added watch count for the projects to the table. If I were to put a requirement on that, maybe 3 watchers?

[MikeMcQuaid]

Have added a suggestion below for 3 forks, watchers or stars.

[Bo98]

To be clear: "or" or "and"?

[MikeMcQuaid]

Whatever the code says (which is consistent with what we do for GitHub/GitLab)

[chenrui333]

yeah, i agree that we should lower down the codeberg formulae' notability check, I will update it.

[carlocab]

A bunch of these REST calls could be handled better and more robustly by the existing open_rest method (mutatis mutandis):

brew/Library/Homebrew/utils/github/api.rb

Lines 212 to 281 in 7b0d468

	def self.open_rest(
	url, data: nil, data_binary_path: nil, request_method: nil, scopes: [].freeze, parse_json: true
	)
	# This is a no-op if the user is opting out of using the GitHub API.
	return block_given? ? yield({}) : {} if Homebrew::EnvConfig.no_github_api?
	# This is a Curl format token, not a Ruby one.
	# rubocop:disable Style/FormatStringToken
	args = ["--header", "Accept: application/vnd.github+json", "--write-out", "\n%{http_code}"]
	# rubocop:enable Style/FormatStringToken
	token = credentials
	args += ["--header", "Authorization: token #{token}"] if credentials_type != :none
	args += ["--header", "X-GitHub-Api-Version:2022-11-28"]
	data_tmpfile = nil
	if data
	begin
	data = JSON.pretty_generate data
	data_tmpfile = Tempfile.new("github_api_post", HOMEBREW_TEMP)
	rescue JSON::ParserError => e
	raise Error, "Failed to parse JSON request:\n#{e.message}\n#{data}", e.backtrace
	end
	end
	if data_binary_path.present?
	args += ["--data-binary", "@#{data_binary_path}"]
	args += ["--header", "Content-Type: application/gzip"]
	end
	headers_tmpfile = Tempfile.new("github_api_headers", HOMEBREW_TEMP)
	begin
	if data_tmpfile
	data_tmpfile.write data
	data_tmpfile.close
	args += ["--data", "@#{data_tmpfile.path}"]
	args += ["--request", request_method.to_s] if request_method
	end
	args += ["--dump-header", T.must(headers_tmpfile.path)]
	output, errors, status = Utils::Curl.curl_output("--location", url.to_s, *args, secrets: [token])
	output, _, http_code = output.rpartition("\n")
	output, _, http_code = output.rpartition("\n") if http_code == "000"
	headers = headers_tmpfile.read
	ensure
	if data_tmpfile
	data_tmpfile.close
	data_tmpfile.unlink
	end
	headers_tmpfile.close
	headers_tmpfile.unlink
	end
	begin
	raise_error(output, errors, http_code, headers, scopes) if !http_code.start_with?("2") || !status.success?
	return if http_code == "204" # No Content
	output = JSON.parse output if parse_json
	if block_given?
	yield output
	else
	output
	end
	rescue JSON::ParserError => e
	raise Error, "Failed to parse JSON response\n#{e.message}", e.backtrace
	end
	end

I wonder if it's worth extracting that to somewhere more generic (i.e. not GitHub-specific) for use here (and likely elsewhere).

[ONLi54tNDa]

Commit

[MikeMcQuaid]

Do we need this? Can we hold off until we do?

[chenrui333]

sure, we can remove that for now (but codeberg's api is very similar to github though)

[MikeMcQuaid]

Have added a suggestion below for 3 forks, watchers or stars.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.