Project duplication with API not keeping triggers

SanderVW

Hello, I'm using the API to duplicate my projects on releases from development to production (as opposed to the UI duplication to save time as there are 30+ projects we duplicate every time).

On duplicating the projects I noticed that the scenario triggers are not automatically enabled in the newly duplicated project, even though they were enabled in the original project. Is there a way to also copy this setting using the API? Or perhaps, in a slightly roundabout method, a way to enable this setting for specific scenario's using the API?

I already tested some of the values for the DUPLICATION_MODE argument of the project.duplicate function (MINIMAL, SHARING, FULL, NONE and UPLOADS_ONLY) but no luck yet as these all do not copy over the enabled scenario triggers. Though I did notice the documention did not mention UPLOADS_ONLY as a possible value so there might be more possible values I am not aware of

Any advice is much appreciated!

Additional note: I should mention that the triggers themselves are duplicated, they are just not enabled. Even though they are enabled in the original project.

---

Operating system used: Windows

SanderVW

What I have decided to do is just get the scenario trigger setting from the old project and set the setting of the new scenario to match:

for scenarioID in old_project.list_scenarios():
  old_settings = old_project.get_scenario(scenarioID['id']).get_settings()
  new_settings = new_project.get_scenario(scenarioID['id']).get_settings()
  new_settings.get_raw()['active'] = old_settings.get_raw()['active']
  new_settings.save()

A bit of a roundabout method but in my case it works.

Turribeach

Project duplication is NOT how you are supposed to release projects from Development to Production. you should be using Project bundles. This is what the Deployer is for. So the first question really is why you have decided this is sound pattern to follow given that you are really going against the flow? (pun intended).

SanderVW

I understand it's a bit of an unorthodox method, I was not the one who set it up. I did discuss it with the person who did but right now it's not high enough of a priority to merit improving above the rest of the development of our flow so I'm afraid we'll have to make do...

I am looking into small ways to minimise the work needed for this release method so if this specific case is possible to do I would love to hear it. Is there a full list of the values the duplication_mode argument accepts?

Turribeach

Sooner or later you will have to realise that you are paying technical debt at every step of the way by the decision to go with a solution that makes no sense. Duplicated projects do not enable triggers since they are not meant to be deployed. You will need to enable the scenarios and their triggers manually using the Dataiku API.

SanderVW

I get where you're coming from and agree that in general it is better to use project bundles but in our case it's not viable. I'm just wondering about the API and want to improve what we have currently.

Turribeach

I prefer:

new_settings.active = True
new_settings.save()

SanderVW

Not all our scenarios have active triggers so I want to directly copy the old settings.

Turribeach

I meant it as I prefer to access the defined property than using the get_raw() method which will fail if the value is undefined in the object. The property may handle that and expose a default value. Also you should only assign it when it's different as otherwise you as wasting a save:

if old_settings.active <> new_settings.active:
    new_settings.active = old_settings.active
    new_settings.save()

SanderVW

I see what you mean now. Yes, I agree it's more efficient that way.