• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Github Webhook Branch Specific

DubStepMad

New Pleskian
Hello,

I've noticed while using webhooks and additional deploy actions that the plesk intergration updates on every branch.

Issue:
I have two websites, one being a beta site for testing new featues, etc.
When I update tHE beta branch the beta site updates and runs the additional deploy actions as I want to.

The other outcome I do not want is that this also triggers on the main (master branch) site and runs the additional deploy actions causing downtime.

After doing a little googling around, I came acrossthat Github does specify the branch triggering the update in their webhook header.

I am not sure if this is the right place to ask but could this be implemented into plesk to stop this issue.

Now I know I can just remove the additional deploy actions from the master site but this then defeats the point of having an autonomous deployment.
 
I am seeing the exact same issue. I created a page and a subdomain (production and staging) and created there two git repositories (twice the same repository). This gives me two webhook URLs which I added both in the repository.
When configuring the git repository, I selected "Automatic deployment" mode and on the folder where it goes to, I specified the branch name on both repositories. This works well for the code (it arrives correctly where it should, staging on staging and master on prod). However the additional deploy actions of both repositories get fired.

So in summary, the additional deploy actions also get fired when the selected branch does not match the pushed branch name.

I cannot imagine a situation where I would expect my deploy actions to get fired when nothing actually deployed on my branch, so I'd also classify this as a bug.
 
I had the same issue and did a workaround in the "additional deploy actions". I'm saving last pulled or current git commit into a file and each time the "additional deploy actions" are executed they first check if the repository's last commit is the same than that saved in the file.

But it would be nicer if they would just be fired by the corresponding branch.
 
I had the same issue and did a workaround in the "additional deploy actions". I'm saving last pulled or current git commit into a file and each time the "additional deploy actions" are executed they first check if the repository's last commit is the same than that saved in the file.

But it would be nicer if they would just be fired by the corresponding branch.
Could you kindly share how you are doing this please?
 
Could you kindly share how you are doing this please?
Nevermind, found it here:

In the meantime, I created a workaround in the script which is called by the "deploy actions" of Plesk:

Bash:
#!/bin/bash

# in case if you need php
export PATH=/opt/plesk/php/8.1/bin:$PATH:$HOME/bin

echo "Auto-Deploy started"
date

# get latest hash of the main branch
# for this command you need a ssh key pair between github and your server
remotehash=`git ls-remote [email protected]:USER/PROJECT | grep refs/heads/main | cut -f 1`
# get hash of the last main commit from file
localhash=`cat .currenthash`

# check if main branch is newer as the latest saved hash
if [ "$remotehash" != "$localhash" ]; then
  # new commit to main: run your scripts for your project here, like:
  composer install --no-dev --optimize-autoloader
 
  # save latest commit hash in file
  echo "$remotehash" > .currenthash
else
  # no new commit to main
  echo "no change found, deploy skipped"
fi

For only a `composer install` you don't need this, but in my project I have to clear the cache of it. This should not happen only because I'm pushing something to any other branch.
 
Back
Top