Open abhvsn opened 2 years ago
In our use case the development appsmith instance and the production one are not the same becaue the production instance is hosted on our client's machine. That also means different users for each organization. If version control is at app level I assume this will be an issue. The ideal situation is, we develop the app in our dev branch, merge the branch into production branch when we're done and have our client only see the production branch's apps all the while maintaining the organization structure(where the app belongs and who can access the apps).
Our organization currently has 13 Appsmith apps. The ideal situation would be we test changes in our development environment and then can push those changes to production via git. Having 13+ new repos is cumbersome and being able to have all our appsmith apps in a single repo would be great!
+1 one for this. Having this one to one mapping is kind of a blocker. At the workspace or even global level would be ideal. For a team with lots of small apps left and right it will save a ton of time.
On top of having more than one app in a git repo, it would also be nice to be able to specify the root path within that repo. Currently it occupies by default the root of the repo and it forces you to have one "appsmith-apps" or something. In a monorepo situation where you might want to have more stuff in the same repo, we can specify the folder appsmith should use for version control purposes.
Hope that makes sense.
+1
When we create multiple dashboard within each team, it would be a good feature to be able to have different repository for each team - allowing them to bundle all their dashboard into one repository. Alternatively, it would be a nice to have feature where similar dashboard / dashboard for each domain could be stored into a single repository.
We currently have 30+ dashboard deployed into production. Having 30+ repository would not make sense in my view.
Looking forward for one repo for many dashboard feature soon!
Thank you.
+1. I think this feature could be rephrased to be: Choose folder to deploy application.
Our use case is similar. We have plenty of repos for deploying in 3 instances (Dev, QA and Prod).
It would be way easier if we just reuse the same git connection to one repo and use folders to split the apps.
It would also streamline the review process in Github once all app developers would be in the repo and I wouldn't need to setup rules for every single repo for review and deploy.
It would also help in bundling version updates by using the same repo.
In summary, this is very much important for a streamlined devops.
Customer Request from Twilio to "Important for supporting many internal teams with centralized governance"
yep, we need it too for bluewind, being forced out of a monorepo is a pain for productivity. The quick fix is to just always put a root folder when syncing appsmith, called appsmith. this way people can have thousands of appsmiths app inside the same folder, and they can have other root folders for other apps.
VERY VERY important for bluewind to coordinate the open source project in a central repo
+1 Pratik from Zuddl requested this.
For comparison, tooljet supports it: https://docs.tooljet.com/docs/2.65.0/gitsync Retool as well: https://docs.retool.com/source-control/
+1
Also on our end, having multiple apps will require to manage multiple Github repos which all will have the same settings and CICD which is a big waste of time. This will make the app development cycle be longer and harder and will miss the point with the no-code solution which is velocity.
Having one repo, whether its monorepo style or not, will solve most of the issues with Git sync.
+1 from customer here.
+4 from customers here and WWT
Is there an existing issue for this?
Summary
Today using the git-sync we have one-to-one mapping between the application within Appsmith and the remote repo, a user on discord asked if we can have a single repo where multiple apps can be committed.
Why should this be worked on?
This can be a good value addition from the perspective of managing multiple Appsmith apps within a single repo
Front conversations