[Feature/Possible-PR] Discord Webhooks

[7twin]

I was thinking of adding discord webhooks to have them report if the deploy failed or not (goes well together with gitea native discord webhooks, which tell whenever commits are pushed), would a PR for that be appreciated or is that against the minimalism of the project and should be kept as a fork?

With something like that: https://github.com/AuroraAri/Discord-Webhooks-PHP/blob/master/src/Client.php it could be dependency lightweight too, by having just one more file or by just re-writing it to be one function inside deploy.php and extend the config to have discord tokens.

[7twin]

Already implemented, the changes can be previewed here: master...7twin:discord-webhooks
Here's also a screenshot how it looks like in both cases:

I am happy to PR if this doesn't go against the project goal of keeping it minimal, though I've went the route of embedding the function, so there's no dependency difference.

Note: I have not had the time yet to check custom avatar and username, but I'll be sure to do before submitting PR.

Edit: Custom avatar works, fixed custom username too, because the discord API changed from using "name" to "username" as the username field.

[rubenreyes2000]

I am hesitant to incorporate this code because it is very specific to a single platform.

My approach would be instead to create a way for you to plug in your own webhook code. I can create a "callback" mechanism that would load a custom PHP file containing a function that handles errors, and another that handles success deployments. These functions would receive the info you need and then you can integrate with the notification system of your choice.

I will make a commit soon with my idea.

[rubenreyes2000]

Take a look at cde8ef6

[7twin]

@rubenreyes2000 I agree it should be more of a "plugin system" indeed and I like your commit, though I would like to have a way to give options to people to choose from existing contributed plugins and for others to contribute theirs too, instead of everybody having to re-implement e.g. the same discord webhook that could be already shipped out for those that would want it.

I have a multitude of ideas on how that could be implemented, e.g. have an array of scripts in the config file instead of a single fire include, call them like you did with just one and each webhook plugin would have its own configuration variables inside of it (kind of losing the central configuration file system for these, but that is already a given by exporting webhooks into external php includes, except if one adds all possible configurations and marks them as optional, similar to how I had it?).

The readme could accommodate for that and list already available plugins and an explaination on how to make your own.

What do you think?

Tried to compress all my thoughts into this message, ask away if something didn't quite make sense.

[rubenreyes2000]

I think we share the same vision.

We can create plugin files, for example: deploy-discord.php that will contain the necessary settings and functionality to handle the callbacks and integrate with the 3rd party system.
On the configuration file, on CALLBACK_FILE you would need to enter the filename of the plugin.

Do you want ahead and make the first plugin for Discord?

[7twin]

@rubenreyes2000 glad we share the same vision! I would make the first plugin, but before that we need to figure out a proper way for the plugin system, so there could be multiple webhooks fired if a user wants to (instead of just one CALLBACK_FILE), I'll look into creating that today and if you approve of it, create the first plugin shortly after.

[rubenreyes2000]

Sounds good, thank you

[7twin]

Here it is: master...7twin:plugin-system

• added plugin autoloader (loaded from config array)
• plugin interface (which plugins must implement from)
• implemented class method checks
• new defined configuration key
• plugin error handling (non-breaking because a webhook not firing should not fatal throw and be silently logged)
• added more success callback keys
• added the discord plugin as a default example of a working plugin implementation
• fixed an issue with the recent change to endScript() where it would display the same message after errorPage()

This should be good to go, if you have a nicer way to prevent the errorPage()+endScript() issue, be free to change it during PR - I'll keep contributor changes open.

Tell me what you think and if you approve of the changes - I'll PR it.

[7twin]

@rubenreyes2000 forgot to tag you in the last post and I am not sure if you're auto-subscribed.

[lyquix-owner]

@7twin - this looks great

I have 2 comments:

1. Plugins are forced to be on the plugins/ directory. I think we should make the locations of plugins an option in the configuration file, to give users flexibility on how they may want to organize their files.

2. The plugin should override its settings if the constants are defined in the configuration file. For example, if I define DISCORD_WEBHOOK in the configuration file, the plugin should use that value and not the default in the code. The reason for this suggestion is that we want to be able to update the files from the repo without fear of overriding our project settings.

Let me know what you think. If you like these suggestions, can you please implement them on your PR?

Thank you!

[7twin]

@lyquix-owner sounds absolutely reasonable to me, will implement it to the PR in the next few hours, though I'd be open to suggestions on how we maybe could enforce plugins of taking care of checking the main config as an override, similar to how the interface enforces specific methods and parameters, to prevent users from submitting plugins that do not do that - at the very least we could include like a plugin contribution guide, where we just note that.

[7twin]

@lyquix-owner implemented both changes, though as previously mentioned, it would be nice to create a webhook plugin contribution guide of some sorts or a way to enforce plugins checking the configuration behaviour, similar to how currently the interface enforces specific methods.

Tell me if I should PR it: master...7twin:plugin-system

[rubenreyes2000]

Looks great!

Quick question, what's the purpose of the file plugins/Plugin.class.php?

[rubenreyes2000]

And yes, we will add information on the documentation about how to use plugins and how to create new ones.

[7twin]

@rubenreyes2000 That is the interface that gets autoloaded together with the plugins, which the plugins implement, to make sure all plugins implement at least the basic webhook functions called by the system.

Will PR in the coming hours!