|Status:||Marked for Closure||Start date:||07/03/2020|
|Target version:||RapidDeploy - 5.0-FIX|
|Affects Version:||5.0-FIX||Additional version details:|
I remember that have already registered ticket about some difficulties with project copying. We discussed that and You said that when creating new project as a copy of one already existing it is normal for it to inherit all base project settings. Including different paths (like SCM repository and Artifact repository paths). I don't know, maybe that really has sense when making two tightly linked projects. I didn't face such necessity until now. :) But, in any case, I'd say that there could be great to have also another one project copying variant when new project copies all settings but has own paths. To eliminate data intersection, to protect from situations when I change one project and another one gets changed just because of faulty configuration.
I don't say that this is very critical place and You are obliged to implement this. :) But that is a feature that could be very nice to have. In our microservice infrastructure we have to have as many projects as many services we have. So there should be some kind of project template that each new project will be copied from. And that's really very simple to forget to edit some data in a new project. And that can lead to a very awful results. I see that problem just because I already did such mistake twice. :) My colleagues are not so experienced in working with RapidDeploy and the probability of fault is even higher.
I'd say that system could have possibility to copy project and to clone it. One operation could make a new linked project (just like it's done now), and other - totally isolated one.
Please let me know what do You think about this. :)
- Tracker changed from Support to Feature
- Status changed from New to Marked for Closure
- Assignee changed from Rafael to Vadim
Sorry for the late response!
This feature was already implemented in RapidDeploy 5.0.21:
"Update project name in plugin value references when it is changed in project creation, copy and import."
It was internally tracked after your suggestion in the ticket #3521 and released with the version 5.0.21 of RapidDeploy curiously the same day you created this ticket.
Now you only need to change the project name and all the references for the "SCM Repository" plugin and the "Artifact Repository" plugin will be updated! :-)
If you updated RapidDeploy to the latest version you should already be able to test it.
Let me know if you have any other concert about this ticket, otherwise I'll just time it out.
Thanks a lot as always for all your feedback! :-)
That's great! Unfortunately I didn't get any info that new version is available, so installed it only after Your message. :)
Yes, I see that project copying goes in different way and project name is dynamically changed in main paths. That's great! :) Thank You for fixing this place.
But... :) Seems that something still goes wrong. I don't know if this is connected to project copying, but see it with copied projects. When base project has some resources assigned seems that those resources go to a child project also (I can see newly created project in a resource usage list). But when I open project general page I don't see any assigned resource. :) Please find attached screenshot.
Also I get very strange error when trying to trigger deployment from Jenkins (error states that "Job Plan has late configuration remain to be configured!" when I know that everything is Ok and it is possible to run deployment job from RD WEB interface without any additional changes). I don't know if these errors are connected, I will investigate and report separately. But You also can try to test it. ;)
So the main question here is about the resources. I don't see them in a child (copied from base) project. Can You please check it?
Strange that I also cannot see resources in available resource list...