ÃÛ¶¹ÊÓƵ

Transcript

Hello and welcome to the Cloud5 interview series. I’m here with Amol Anand, who is a Principal Engineer here at ÃÛ¶¹ÊÓƵ Engineering. Today he is going to talk about publish events, which I’m extremely excited about. Amol, can you talk about some of the events that are available to us when content either gets published or unpublished? Yeah. When content gets published or unpublished, what we do is we release some GitHub events that you can then listen to using your GitHub actions and trigger anything that you need to do programmatically. Fantastic. Can you talk about some of the use cases of this? Yeah. It’s not a very common use case, I would say, but we have seen in some projects where you need to trigger some event in a down party system or you need to hit some endpoint when content gets published or unpublished, either ways, and in those cases, this is pretty helpful to do. Makes sense. Can you actually give us a specific example? I think that would be really helpful. Yeah, absolutely. Let me share my screen. Give me a second. All right. As you can see here, I have a project open in Edge Delivery, and you can see I have a couple of workflows that are created here. I’m going to go to the publish events workflow. I have an unpublished event. The on is basically what event we’re listening to. Repository dispatch and then the type of the repository dispatch is resource published. That’s the one that we’re listening to in this particular event. Then I have a job that prints out some details about the payload. Then I’m going to trigger based on some if condition and it matches certain paths. I’m going to trigger a bunch of things, whether it’s hitting some endpoint or hitting save or some endpoint, etc. Then I have some conditions here. If the folder starts with test, I want to hit the test endpoint. If it starts with state, I want to hit the state endpoint, so on and so forth. I can then get as elaborate as I needed or as simple as I needed, and respond to this event. The way it would look like if you went to your GitHub Actions folder, you can see that on publish events, whatever, every time the resource published event came in, it basically triggered all the action and all the code that I wanted to trigger. I can go and drill down and see any details. Similarly, there’s an unpublished workflow as well. Whenever things got unpublished, I also then ran this my appropriate workflow and did whatever I needed to do programmatically. That’s basically how that works. Yeah, that’s super useful and I can definitely see if you need to integrate with other systems when something happens, something is published or unpublished. I can see how that would be extremely useful to developers in terms of integration. Amal, thank you for your expertise on this, and we will talk to you next time. Appreciate it. Awesome. It’s nice talking to you, James. Nice talking to you. Bye now. Bye.