Planning Analytics

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Hi Hubert, 

are there any updates on this issue? 

I look forward to your feedback 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Hi Florian,

No updates I'm afraid, but not forgotten either, it's been discussed, just didn't make it to the top of the list yet. I had already referenced this conversation in the issue I created so we'll for sure update you when we get this done.

Hi Hubert, 

are there any updates on this issue? 

I look forward to your feedback 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Hi Florian,

No updates I'm afraid, but not forgotten either, it's been discussed, just didn't make it to the top of the list yet. I had already referenced this conversation in the issue I created so we'll for sure update you when we get this done.

Hi Hubert, 

are there any updates on this issue? 

I look forward to your feedback 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Thanks Hubert. If it is helpful, I can speak with our "ticketmaster" to create an official ticket for this issue. What do you think?

Hi Florian,

No updates I'm afraid, but not forgotten either, it's been discussed, just didn't make it to the top of the list yet. I had already referenced this conversation in the issue I created so we'll for sure update you when we get this done.

Hi Hubert, 

are there any updates on this issue? 

I look forward to your feedback 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback. 

Hi Florian, it won't hurt but doubt it would change anything either. Trust me, it's on the list and coming, and not just because I need it fixed myself ;-)

Thanks Hubert. If it is helpful, I can speak with our "ticketmaster" to create an official ticket for this issue. What do you think?

Hi Florian,

No updates I'm afraid, but not forgotten either, it's been discussed, just didn't make it to the top of the list yet. I had already referenced this conversation in the issue I created so we'll for sure update you when we get this done.

Hi Hubert, 

are there any updates on this issue? 

I look forward to your feedback 

Hi Florian,

I ran into the exact same issue recently when I was demoing the use of GitHub actions with a repository containing the TM1 model (sample repo can be found here, note that the commits in the repo are deliberate to show of the GitHub actions in action during the demo, planning to add some generic, REST Client for TM1 Developers based, test framework later).

Whilst I was doing my work/demo in VSCode, the fact that I need additional files in that repo, the GitHub workflow descriptions and my scripts in my case, would indeed preclude TM1's GIT integration itself from interacting with such repo as that would indeed delete those file every time (and using a branch and correcting that every time, which I've done using VSCode, is very cumbersome).

We already have an exception for the ReadMe file and we'll have to come up with a, backwards compatible, way to allow you to have additional files in such repo. I'll create an [internal] issue for this and get this improvement kicked off. 

Hello, 

we would like to version all our data pipelines consisting of DBT, Dagster, TM1.py and TM1 objects like TI processes in a single Git repository. 

1) Our first approach was to dump the TI processes with TM1.py and transfer and push the JSON to our repository. But the workflow is not the best.

2) Our preferred approach is to use the TM1-Git integration. The problem is that TM1 deletes all existing files that do not belong to TM1 when we do a push. 

Is there a solution to this problem? It would be beneficial if we could specify a folder where tm1 stores all tm1 objects so that the rest of the repository remains in its current state. 

Im looking forward to your feedback.