Redmine › SCM Creator (+Github)

+1
I was just searching for a way to achive this. In my case I would like to be able to select the post-commit-hook that will be copied for the newly created repository. If I could register such a creation script I could do that by having different creation-scripts available which copy the correct hooks and perhabs also do some other things (e.g. do a checkout of the project to /var/www/myProject for testing).

Also it would be nice if you could pass parameters to the scripts (e.g. a path to checkout to in /var/www). Perhabs you could use a textfield for the scriptpath and anything that follows the path will be passed as parameter... ?

Would be nice to have such a feature available!

Regards

Andriy Lesyuk wrote:

Thanks for the suggestion!

Thanks for picking it up!

I guess it should be in scm.yml... (Why in Settings → Repository?)

Because you could select project-specific scripts or pass parameters to the script

Jonas Götze wrote:

Also it would be nice if you could pass parameters to the scripts (e.g. a path to checkout to in /var/www). Perhabs you could use a textfield for the scriptpath and anything that follows the path will be passed as parameter... ?

In my case I would need this, as we have at least 2 different project types, which need different commit-hooks. I could choose and copy the correct hook in my creation-script, but I would need some identifier (apart from projectname).
So it should be possible to either choose the fitting script on project-creation or pass a parameter to it which enables the script to decide correct.

Best would imo be if you could define some creation-/delete- scripts in scm.yml and these will be presented in a dropdown in Settings → Repository of the project along with an empty value for no script-execution at all.
The project creator would then be able to just choose one of the predefined scripts and create the repository.

What do you think?

If we assume that repo name is the same as project identifier then we can use project identifier. Repo type can also help us in distingushing...

Andriy Lesyuk wrote:

Jonas, what argument will be useful for you?

I guess only userdefined arguments will be...
Somewhat like a creation-Profilename whith that the creation-script can work as a dispatcher.
I doubt the project-name can always garantuee that, in our case at least.

Why would you need to store them in the database?
Create and delete a project (and repository) should only occur once I guess - so I think displaying the possible values in a dropdown or something else will happen once and then dissappear like the “create new Repository"-Button does.

Perhabs somthing like this:
scm.yml

production:
   auto_create: false
   deny_delete: true
   svn:
     path: /var/lib/svn
     svnadmin: /usr/bin/svnadmin
     hooks: /usr/share/subversion/hook-scripts
     url: svn
     availablecreationscripts:
       Script1: /usr/share/subversion/do-something-on-creation.sh
       Script2: /usr/share/subversion/do-something-else-on-creation.sh
       Script3: /usr/share/subversion/do-something-weird-on-creation.sh

If no scripts are defined the dropdown will not appear at all. If there are some scripts defined, there could (should?) also be the empty (default) option so you could still create a repository and use no script at all.

Regards

I don’t know why but I don’t like the idea of new select field... While it’s possible to show it on creation it can be impossible (or very hard) to show it on deletion... Anyway I will think about this.

Maybe some custom field value can help you? Is there anything that differs these two project types? Parent project?..

I thought this thing over and must agree that it should be only in scm.yml. The reason for this is because these are more like system settings which project admins aren’t really interested in (by definition they don’t even have access to the operating system) and they might get confused if they see such input/select fields in GUI that they know nothing about. So my vote is for:

ceationscript: <script_path>
deletionscript: <script_path>

I believe the case described by Jonas is likely unusual... The plugin can’t cover all such cases! But I want to do as much as possible to help Jonas.

Jonas, what about this kind of solution (requires programming in script):

You can add a custom field e.g. “Project type” of “List” type having two possible values: e.g. “Type1” and “Type2”. Project managers will be required to select the “Project type” when creating a project. With this approach you will have a field which identifies your project types... And this field will be understandable to users unlike script names which can confuse. Having project identifier you can then fetch custom field value from database in your script... What do you think? I’m ready to help you implement such script if you agree.

Andriy Lesyuk wrote:

I believe the case described by Jonas is likely unusual... The plugin can’t cover all such cases! But I want to do as much as possible to help Jonas.

Thanks a lot for that! I really appreciate it.

Jonas, what about this kind of solution (requires programming in script):

You can add a custom field e.g. “Project type” of “List” type having two possible values: e.g. “Type1” and “Type2”. Project managers will be required to select the “Project type” when creating a project. With this approach you will have a field which identifies your project types... And this field will be understandable to users unlike script names which can confuse. Having project identifier you can then fetch custom field value from database in your script... What do you think? I’m ready to help you implement such script if you agree.

Thanks for your offer - this suggestion sounds promising. I did not think of such a solution.
So in my creation script I would need to select the project-Record via mysql using the project identifier passed to the script - right?
I am new to shell-Scripts so I am not sure yet how I can use the result of the Query in the Script but I think I will figure this out. With that information I could then select the fitting commit-hooks and copy them to the passed project-Repository-Path and do everything else what is needed for the project type.

Thanks again for your efforts.

Regards

This option is going to replace hooks (see: #1886)! What do you think?

Thanks for your work!

Andriy Lesyuk wrote:

Specially for you, Jonas, script will have access to project custom fields! For example, if your custom field name is “Very specific type” there will be environment variable SCM_CUSTOM_FIELD_VERY_SPECIFIC_TYPE... I believe many custom fields won’t harm scripts...

This sounds very nice. I’ll try it as soon as I have some time again Thanks again!

Regards