Hi Daniël,

Thanks for sharing your idea. 

Can you please describe the scenario where you felt that need?  

Thank you

Hi João,

Scenario 1

So we use BDD Testing Framework, to run regression tests in TST environment for multiple applications. This is scheduled via a Jenkins CI integration (From DEV --> TST --> QA) and is scheduled every day after workhours.

However, we would like run the BDD tests more frequently already in DEV to identify breaking changes faster. What we don't want is to manually kick of the publish of a solution with all the modules that need their dependencies to be refreshed in order to run the BDD tests automatically.

We would like to automate the process of refreshing the dependencies of the relevant modules and that performing the BDD Tests.

Scenario 2

In a large application factory, where multiple teams work on multiple applications, we could schedule a republish of the complete factory after working hours. 

I am aware that we have to manage the disk usage due to a higher amount of versions created, but for that we have already tools that can be scheduled.

Regards,

Daniel

This is good if there is a way to determine which modules needs republishing, since without it there would be instances of republish with no change at all. This can be problematic when tracing back changes after a long time wherein constant republish without change will simply increment version number burying the relevant version.

In case such condition check is not yet available at least allow scripted triggers for publishing which can be executed in automation servers like Jenkins CI. I believe this will at least resolve both scenarios albeit with more setup procedures than the original idea.