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

Automated status checks of the resolvers #187

Closed
cre8 opened this issue Apr 9, 2021 · 5 comments
Closed

Automated status checks of the resolvers #187

cre8 opened this issue Apr 9, 2021 · 5 comments

Comments

@cre8
Copy link

cre8 commented Apr 9, 2021

Since some networks seems to be down or loose support over the time, it would be useful to have a tool that checks for availability and correctness of time. This could be useful for the future since the amount of did methods will grow.

Reporting tool:
The repository offers a tool that will run the code under quickstart and validates the results. The table includes the following rows:

  • docker image is accessible
  • the image is listed in the w3c spec table
  • the curl request returns a 200 response
  • the curl request returns a valid did document

The tool could be used to update the drivers table by adding another row like (check). The value can be updated by a commit but the better solution would be to use badges. When using badges we need a hosted service that will check the information.

@BernhardFuchs
Copy link
Member

BernhardFuchs commented Apr 14, 2021

Thanks for the constructive feedback. It's always helpful to hear how we can improve the Universal Resolver to benefit the community.

Regarding your bullets points:

  1. docker images have to be available on a public accessible registry. I can't recall a case where the image went offline. Most of broken drivers are a result of either problems in the infrastructure (e.g. ledger) or outdated implementation.
  2. In the last DID WG call we discussed the possibility to make it mandatory for drivers to be listed in the w3c spec table and the proposal got positive feeback. There wasn't a final decision made but we will further discuss the topic at the next DID WG call and on IIW next week.
  3. In the repo under the ci-folder is a smoke-test action which is run after each deployment. Atm the results are not collected and displayed and mainly used for debugging deployments. The script can also be run manually against any Universal Resolver deployment (described in the README of the action). We already planned to utilize these results for status checks of the drivers
  4. The official did-test-suite will be finalized in the next couple of weeks and we plan to integrate it to the Universal Resolver workflows once it is finalized.

We don't know yet how we will display the results of the automated checks but thanks for the suggestions. There will be at least one session on IIW next week about that topic, so feel free to jump in.

@cre8
Copy link
Author

cre8 commented Apr 14, 2021

@BernhardFuchs maybe there is a chance to use actions with a schedule to do this.

Sounds cool, will check up if I have time for IIW!

@BernhardFuchs
Copy link
Member

@cre8 yes, my idea was to use a cron job to collect the results. Not sure yet which interval but I'm happy to get some input on this topic.

@peacekeeper
Copy link
Member

We discussed this on the 29 Sep 2021 Universal Resolver work item call and thought that most of the items in this issue have been addressed (e.g. by updating the Driver Development page).

We created two new issues about remaining smaller topics, and propose to close this one. @cre8 do you agree?

@cre8
Copy link
Author

cre8 commented Sep 30, 2021

@peacekeeper sounds good :)

@cre8 cre8 closed this as completed Sep 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants