You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My two cents, in case anyone else runs into any of these issues. While the following remarks are pretty obvious, I'm writing them down in case someone happens to overlook these things like I did.
In order for the plugin to correctly clone any repo, you should ensure the following:
Make sure that the user running Redmine (Apache's user, in my case) has write permissions in the repositories folder. By default, the plugin uses {Redmine's root]/repos.
Make sure that the user running Redmine (again, Apache's user in my case) has read access to the repository you are trying to clone. That means that if it's not public, you need to make sure the user can authenticate. In my case, I had to create an SSH key for the www-data user (the user running Redmine) and associate its public SSH key to a user with read access to the repository (in Gitlab, in my case). While I'm not a 100% sure this is the right way to do it, I couldn't find a better way (other than making the repo public, that is). I did something like what's explained here: https://www.portent.com/blog/design-dev/github-auto-deploy-setup-guide.htm
Having generated the SSH key and given the user read access to the repo, one final step: switch to your user (su www-data, in my case) and attempt to clone the repo somewhere (temp folder), in order to check that it works, and more importantly, to make sure you accept the remote server's RSA key; otherwise, the plugin won't be able to clone the repo (of course, I guess the proper way to do this would be to import the key rather than accepting whatever key it reports, but in my case, it was somewhat too complicated).
One last thing, I'm not sure if there's a way around this: the repo seems to be cloned the first time the plugin's hook receives a commit trigger. So, if you are looking at the repo tab and it's empty, try committing something in order to have the plugin clone the repo (of course, you must have enabled the option "Fetch a repository by an external webhook" first)
The text was updated successfully, but these errors were encountered:
My two cents, in case anyone else runs into any of these issues. While the following remarks are pretty obvious, I'm writing them down in case someone happens to overlook these things like I did.
In order for the plugin to correctly clone any repo, you should ensure the following:
su www-data
, in my case) and attempt to clone the repo somewhere (temp folder), in order to check that it works, and more importantly, to make sure you accept the remote server's RSA key; otherwise, the plugin won't be able to clone the repo (of course, I guess the proper way to do this would be to import the key rather than accepting whatever key it reports, but in my case, it was somewhat too complicated).One last thing, I'm not sure if there's a way around this: the repo seems to be cloned the first time the plugin's hook receives a commit trigger. So, if you are looking at the repo tab and it's empty, try committing something in order to have the plugin clone the repo (of course, you must have enabled the option "Fetch a repository by an external webhook" first)
The text was updated successfully, but these errors were encountered: