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

Reduce calls to clearlydefined #301

Open
akurtakov opened this issue Dec 7, 2023 · 2 comments
Open

Reduce calls to clearlydefined #301

akurtakov opened this issue Dec 7, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@akurtakov
Copy link
Contributor

Clearlydefined being less and less stable makes me wonder whether in case it is down licensetool should fail or it should list not approved artifacts so they are reported to eclipse and hopefully the bot kicks in and adds records in it's own database thus clearlydefined being queried less often and prevent many cases like today it being down https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/actions/runs/7127239536/job/19406740416 .
Isn't the bot that checks iplab issues checking clearlydefined? If that's the case, everything that's approved by clearlydefined should get a record in EF database created by the bot on request and both sides benefit by having less queries around.

@akurtakov
Copy link
Contributor Author

@waynebeaton wdyt?

@waynebeaton
Copy link
Member

The bot that processes IPLab issues doesn't check ClearlyDefined. I decided that when we're asked to review, we review.

I estimate that something like 20% of our approvals come from ClearlyDefined. I don't love the idea of adding that to the IP Team's work queue.

Having said that, providing more resiliency is good. I have a couple of thoughts...

We should add a "keep trying" option. Currently, when there's a failure to connect, it just fails. This was intentional to avoid prolonging calls/builds while we wait for timeouts. But we can be more resilient in the face of an HTTP 429 or 504 (the IPLab bot already does this). Whether or not we retry should be configurable to let the committer decide whether or not to potentially add the additional time required to retry (possibly multiple times).

Ultimately, I think that you're probably right and we should reduce our dependency on ClearlyDefined. My initial thought is that "we've failed to get a response from ClearlyDefined, so create a review issue" should be an option that is off by default. But... this is an option that committers don't want/need to understand and don't care enough about, so it's probably something that should be on by default.

@waynebeaton waynebeaton self-assigned this Dec 7, 2023
@waynebeaton waynebeaton added the enhancement New feature or request label Dec 7, 2023
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