Resolved Git extension ignoring branch for additional deployment actions

[secato]

TITLE:

Git extension ignoring branch for additional deployment actions​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk Onyx 17.8.11
Ubuntu 18.04
Git extension: 1.1.1-228
Remote repository: Bitbucket​

PROBLEM DESCRIPTION:

The "additional deployment actions" ignore the branch specified in the settings. It runs whenever a push to the remote repository is made.​

STEPS TO REPRODUCE:

1. Configure the git extension o pull from a bitbucket repository and deploy from a specific branch
2. Add plesk webhook to bitbucket repository
3. Create additional deployment actions
4. Push something to the repository

ACTUAL RESULT:

The Additional Deployment Actions run whenever a push to the remote repository (bitbucket) is made. It runs for all branches and not only the target branch specified before in the GIT Extension.​

EXPECTED RESULT:

Additional Deployment Actions should run only when the specific target branch was updated.​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[IgorG]

Thank you!
I confirm it is known issue EXTGIT-64

 

[ivanargulo]

I'm having the same problem in the latest version 18.0.26. Is there any ETA for this bugfix?

 

[IgorG]

I'm having the same problem in the latest version 18.0.26. Is there any ETA for this bugfix?

Should be fixed in Git extension version 1.2.0.
At the moment I have no ETA.

 

[florianmuellerCH]

I just saw that there is a duplicated issue on this matter: Issue - Github Webhook Branch Specific

Would be cool to have this solved in the near future as these deploy tasks are really helpful!

 

[remy]

Old issue, but it seems to persists until today.

Would be great to get a fix or a workaround

 

[Hans | Pixel Creation]

@IgorG is there any news on the status of this issue?

Whenever I push to my staging branch, the production is also running the scripts that are now governed by the Laravel Toolkit extension.

 

[remy]

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

#!/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.

 

[Hans | Pixel Creation]

The problem is that we use Laravel Toolkit to manager the deploys of our Laravel projects. Thre the 'deploy actions' is just one of the steps in the deploy procedure.

Some people may be helped by your script. Laravel Toolkit users, unfortunately, are not.

 

[captainhook]

3 years on and this still hasn't been fixed and the Git extension hasn't seen an update since 13 April 2021 (Change Log for Plesk Onyx).

@IgorG is there any update at all on EXTGIT-64 since May 7 2020?

 

[Peter Debik]

EXTGIT-64 has not received priority. Sometimes this means that a very few number of users are affected or actually need exactly the scenario, while many other things that affect a large number of users need to be worked on first. Also this issue is not a blocker. As developing capacities are not endless, Plesk focuses on the high priority issues that a large number of users need or that are business critical to provide a stable platform. Issues that can be worked around cannot be put first, but are also not forgotten.

 

[captainhook]

*every* Git extension user is affected. I appreciate development capacities are not endless but 3 years is an insanely long time for a rather small fix - a hash check. We've seen Plesk pricing increase at least 3 times since this bug was reported. This bug is simply not a priority.

Anyway, thanks to @remy for the workaround.

 

[Hans | Pixel Creation]

EXTGIT-64 has not received priority. Sometimes this means that a very few number of users are affected or actually need exactly the scenario, while many other things that affect a large number of users need to be worked on first. Also this issue is not a blocker. As developing capacities are not endless, Plesk focuses on the high priority issues that a large number of users need or that are business critical to provide a stable platform. Issues that can be worked around cannot be put first, but are also not forgotten.

Thank you for the openness.

Is consideration given to the complexity of a problem? This seems like low hanging fruit to me; a simple solution that doesn't require much effort.

 

[captainhook]

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

#!/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.

Hi remy,

I tried this but it seems to be returning blank for the remotehash. Any idea what could be causing this?

Thanks

 

[captainhook]

Hi remy,

I tried this but it seems to be returning blank for the remotehash. Any idea what could be causing this?

Thanks

I managed to get it to work, had to do:
remotehash=`git ls-remote --heads [email protected]:x/x refs/heads/master | cut -f1`

 

[Hans | Pixel Creation]

This issue has been resolved as of at least May 3rd!

@Peter Debik can you back this up?

 

[Peter Debik]

EXTGIT-64 has not been resolved yet.

 

[Hans | Pixel Creation]

I have received message from a developer that this issue has been resolved.

I just tested it by pushing to a develop branch of a test project and noticed the staging environment was updating (php artisan down), but the production environment wasn't.

The changelogs for 18.0.53 mention "The Git extension now respects the selected branch when requesting a webhook."

So it looks like it has been resolved since 18.0.53, which released on the 6th of June.

 

[Peter Debik]

Could you please send me either the name or the ticket ID in a private message so that I can ask? The change log does not include a reference to the internal case, and EXTGIT-64 which was previously identified as the cause for the branch issue has not been resolved here yet. I'd like to as the developer what the full status is.

 

[Peter Debik]

Meanwhile and with the help of @Hans | Pixel Creation I could clarify this with staff. Indeed, the issue has been solved, but unfortunately it was done in a different case with a different ID EXTGIT-304, so it was not clear or me that it was solved. Anyway, according to that other case it can be considered solved.