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

[BD-32] Hooks framework documentation #27157

Merged

Conversation

felipemontoya
Copy link
Member

@felipemontoya felipemontoya commented Mar 26, 2021

Description

This PR adds a document to the docs/guides directory that explains the generalities of the hooks framework, gives examples of usage and lists the available events so far.

We created a supporting library that is a complete and functional example and we mention it in the document: https://github.com/eduNEXT/openedx-events-2-zapier/

Testing instructions

The main objective of the PR is to add the documentation. No testing is necessary other than the rst docs compiling correctly.

Deadline

  • We already merged the openedx-events part of the hooks framework, this PR should be merged before maple is cut so that the documentation is present for developers that want to try it out.

@openedx-webhooks
Copy link

openedx-webhooks commented Mar 26, 2021

Thanks for the pull request, @felipemontoya! I've created BLENDED-808 to keep track of it in Jira. More details are on the BD-32 project page.

When this pull request is ready, tag your edX technical lead.

@arch-bom-gocd-alerts
Copy link

📣 💥 Heads-up: You must either rebase onto master or merge master into your branch to avoid breaking the build.

We recently removed diff-quality and introduced lint-amnesty. This means that the automated quality check that has run on your branch doesn't work the same way it will on master. If you have introduced any quality failures, they might pass on the PR but then break the build on master.

This branch has been detected to not have commit 2e33565 as an ancestor. Here's how to see for yourself:

git merge-base --is-ancestor 2e335653 fmo/initial_hook_framework_docs && echo "You're all set" || echo "Please rebase onto master or merge master to your branch"

If you have any questions, please reach out to the Architecture team (either #edx-shared-architecture on Open edX Slack or #architecture on edX internal).

@felipemontoya felipemontoya force-pushed the fmo/initial_hook_framework_docs branch from 4527957 to 5d7df36 Compare August 20, 2021 22:45
@felipemontoya felipemontoya marked this pull request as draft August 20, 2021 22:48
@felipemontoya felipemontoya force-pushed the fmo/initial_hook_framework_docs branch 2 times, most recently from ec829db to c034bb1 Compare September 29, 2021 22:40
@felipemontoya felipemontoya marked this pull request as ready for review September 29, 2021 22:42
@felipemontoya
Copy link
Member Author

I updated this PR so that it reflects the actual status of the openedx-events usage.

Tagging some people that might be interested in this docs.
@regisb @robrap @bradenmacdonald @ormsbee and @mariajgrimaldi

@felipemontoya felipemontoya changed the title [BD-32 ]Hooks framework documentation [BD-32] Hooks framework documentation Sep 29, 2021
@felipemontoya
Copy link
Member Author

@diegomillan fyi

Comment on lines 175 to 177
* - `STUDENT_REGISTRATION_COMPLETED <https://github.com/eduNEXT/openedx-events/blob/main/openedx_events/learning/signals.py#L18>`_
- org.openedx.learning.student.registration.completed.v1
- Active | `location <https://github.com/edx/edx-platform/blob/master/openedx/core/djangoapps/user_authn/views/register.py#L258>`_
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to be a blocker to these initial manual docs, but what do you all think of instead (or in addition) adding the following above the send_event call?:

# .. event_implemented_name: STUDENT_REGISTRATION_COMPLETED

We could then auto-generate this section using a sphinx plugin.

  1. We could easily pull in the line info of the implementation.
  2. We could add linting to ensure any imported events get annotated.
  3. It would be trickier (but I assume possible?) to pull the definition information as well. Or, the doc could instead just have a single link to the published document of event definitions.
  4. Note: The current manual docs are a little risky in terms of event definition version information, because that is related to the version of the openedx-events library that happens to be used at the time. Do the docs need reminders on when to update docs, or do you think that is all obvious?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be very happy about something that lets us auto-generate this docs with sphinx.

Adding the event_implemented_name annotation would be great to make sure that the docs are up to date. I had thought about writing a script for this doing string search only, but adding the annotation and the linting is way more robust I think.

About 3) I don't know enough about sphinx plugins to know if pulling the definition annotations is easy or even possible, but from the perspective of a developer reading this docs I think that would be the best outcome.

We could also link the definitions to the specific version of the openedx-events library that the platform currently uses. This way there is no slow drift in the exact line where the definition is written.

About the reminders of when to update this docs, I really think that after a period of rapid growth in the available events it will stabilize and will change very seldom. I think as long as we update this once before releases are cut we are sufficiently on the clear. I suppose it depends on how automatic we can make it.

Copy link
Member

@mariajgrimaldi mariajgrimaldi Oct 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi there @robrap

After you mentioned docs generation in PR Events Definition, I went ahead and implemented this:

  1. Sphinx plugin for events annotations: [BD-32] docs: add documentation for Open edX Events code-annotations#72
  2. Code annotations config: feat: add sphinx configuration for Open edX Events eduNEXT/edx-platform#236
  3. Pylint linter for events annotations: feat: add lint checker for Open edX Events code-annotations edx-lint#176

It's a bit rough on the edges, but I think it could work as a POC. What do you think?

How it looks after running make technical-docs:

image(1)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mariajgrimaldi: I look forward to checking that out more soon. I'm working on getting Django upgrade over the line, so it might be a bit. Given that, I just want to confirm that your post is just about the already existing annotations for the event definitions, and isn't yet a response to my note about annotating the implementations, right? Thanks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for answering @robrap. Yes, they are based on the existent annotations :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mariajgrimaldi: In general, looks good. Let me know when they are ready for review and I'll either review or help find a reviewer. Thanks.

@felipemontoya
Copy link
Member Author

@robrap seeing how the automatic docs will take more time and how having some documentation that gets the ball rolling on usage would be necessary before maple is cut, would you approve that we merge this now?

Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@felipemontoya: My notes around automating are all non-blocking ideas for the future. Although, we could consider adding the annotations sooner rather than later, even if we don't yet automate documentation around them. However, even the annotation idea is non-blocking for this PR.


* - `SESSION_LOGIN_COMPLETED <https://github.com/eduNEXT/openedx-events/blob/main/openedx_events/learning/signals.py#L30>`_
- org.openedx.learning.auth.session.login.completed.v1
- Active | `location <https://github.com/edx/edx-platform/blob/master/openedx/core/djangoapps/user_authn/views/login.py#L306>`_
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Before merging] I am guessing these links will break because they all share the same text (location), but have different URLs.

  1. Please test this and the rest of the changes by building the docs locally.
  2. You can probably fix these by making them anonymous using a double-underscore at the end (e.g. __).

[Non-blocking feedback] Also, I wonder if we could come up with a replacement for the word location? Because the term is general, it is unclear which link will bring you to the definition and which to the implementation, until you follow them of course. How do you feel about event trigger, or something like that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not know this about the rst links. Thanks. I tested running make technical-docs and it build in my devstack.

I added a note at the beginning of the list about the two links and changed the 'location' for a date added. This also removes the status since we really don't have a clear expectation of what goes there or what does active mean. Instead I'm writing the date the event was added to the platform with the idea that a developer sees it and they can figure if the event has been in the platform for long it is likely more stable.

This idea about the dates is something we could further extend to the annotations in the openedx-events library. The moment an event is created, we can put an experimentan_until annotation. This way, even if the original dev does not go back to that repo to say the event is no longer experimental, but fully supported or active a dev looking at this in the future can extrapolate from the date.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to get this up here to be able to comment today. Tomorrow I'll add the annotations to the links since I'm closing my working day now.


Index of Events
-----------------

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Non-blocking idea] Consider adding brief introductory text. Things to possibly mention:

  1. The name of each event is linked to its definition.
  2. The location links to the event trigger implementation.
  3. How will status be used? Do we imagine this will eventually be Active or Deprecated?
  4. Maybe note that this index represents the subset of Open edX events implemented in edx-platform?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added the introduction. About 3. I removed it with the rationale from the other comment.

@felipemontoya felipemontoya force-pushed the fmo/initial_hook_framework_docs branch from cd955b2 to 6207f82 Compare October 8, 2021 15:02
@felipemontoya
Copy link
Member Author

@robrap you are right about the dates. I changed to the standard format used in toggles.

Also I added the annotations at the triggers.

Do I have your approval to merge when the tests passes?

@felipemontoya
Copy link
Member Author

@BbrSofiane I'd like to have this documentation merged before we tag the Maple branches. I'm waiting for the green build and an official review approval. Are those branches being tagged today?

@BbrSofiane
Copy link
Member

@felipemontoya It should be fine, we are tagging the branches next Friday.

use them to change the functionality of the platform as needed and still be able
to migrate to newer open releases with very little to no development effort. In
the case of the events, this is detailed in the `versioning ADR`_ and the
`payload ADR`_.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this description of events vs filters very clear and informative. Could you please add some information about the technical implementation? In particular, I think that users would need to know whether events are synchronous or asynchronous.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy you found it clear and informative. I added a paragraph with technical considerations below this one.

@felipemontoya felipemontoya force-pushed the fmo/initial_hook_framework_docs branch from 6207f82 to c947616 Compare October 13, 2021 20:10
Includes:
- general documentation
- links to individual events definitions and location
- adding examples to events docs
- adding annotations at the trigger location
@felipemontoya felipemontoya force-pushed the fmo/initial_hook_framework_docs branch from c947616 to 678c159 Compare October 13, 2021 20:28
Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@edx-status-bot
Copy link

Your PR has finished running tests. There were no failures.

@felipemontoya felipemontoya merged commit f12ad2f into openedx:master Oct 14, 2021
@openedx-webhooks
Copy link

@felipemontoya 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.

@felipemontoya
Copy link
Member Author

Thanks to everyone for the comments and for helping us make this a better started documentation.

@edx-pipeline-bot
Copy link
Contributor

EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production.

@edx-pipeline-bot
Copy link
Contributor

EdX Release Notice: This PR has been deployed to the production environment.

1 similar comment
@edx-pipeline-bot
Copy link
Contributor

EdX Release Notice: This PR has been deployed to the production environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blended PR is managed through 2U's blended developmnt program merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants