Skip to content

Automate reporting for BROKEN libraries #70

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

Open
SableRaf opened this issue Apr 28, 2025 · 2 comments
Open

Automate reporting for BROKEN libraries #70

SableRaf opened this issue Apr 28, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@SableRaf
Copy link
Contributor

SableRaf commented Apr 28, 2025

Right now, broken contributions are only visible in contributions.yaml through the status: BROKEN flag.

If a contribution go missing, we have to wait for someone to report that they don't appear in the contribution manager (like here for example)

It would be helpful to automate the reporting process when a library is first marked as BROKEN.

For example, we could open an issue automatically when a library is reported as BROKEN for the first time.

On a related note, we could add optional fields in contributions.yaml and submission issue template for the repository URL and GitHub username(s) of the author(s). This would make it easier to tag maintainers when their contribution goes down.

Would love to hear thoughts on this. Happy to help if we decide to move forward!

@mingness
Copy link
Collaborator

mingness commented May 7, 2025

Great idea @SableRaf , it would really help keep an eye on the state of the contributions.
In addition to this, I'd want to check the code that pings the urls, to make sure that it's giving the url a chance. But what you are suggesting, the surfacing of the "broken" urls, will help in identifying the cases when the ping fails.
I think a great first step would be to create issues when a library is "broken" just to surface to ourselves that this happened. only when we are completely happy that the code is fully robust, let's notify maintainers.

with regards to the optional field for the github username in the issue template, which is then added to the contributions.yaml, that sounds good to me.

@SableRaf
Copy link
Contributor Author

SableRaf commented May 7, 2025

Thanks @mingness!

I made a PR to update the issue templates, but then realized that since we generate contributions.yaml from the properties files, the properties files should be the source of truth for these new fields as well. Right?

We could add the following to release.properties in the processing-library-template repo:

# (Optional) A URL to the source repository for your library (e.g., https://github.com/yourUser/yourLibrary).
repository_url=

# (Optional) Your GitHub username. Useful for linking contributions.
github_username=

# (Optional) The SPDX identifier for your library's license (e.g., LGPL-2.1-or-later).
license_spdx=

Then could add optional properties to add_new_contribution_to_yaml.py something like so (excuse my Copilot, I'm not too familiar with Python):

# Define a mapping of properties to YAML fields
optional_fields = {
    'repository_url': 'repositoryUrl',
    'github_username': 'githubUsername',
    'license_spdx': 'licenseSpdx',
}

# Add optional fields if present
for prop_key, yaml_key in optional_fields.items():
    value = props.get(prop_key)
    if value:
        props[yaml_key] = value
        del props[prop_key]

Let me know if I'm on the right track!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants