Bump
1 Like
And I just made the mistake of not selecting a non-prod target and published what shouldn't have been published to prod!!!
This really needs attention. Why Production is the default target for my project is extremely frustrating.
2 Likes
As a workaround, you can set your Production target to Usage = Development and a test target to Usage = Production. The target set to Usage = Production is the default option in the Publish modal.
This ensures the actual Production environment is not the default target when clicking Publish.
There will be a spin off issue in doing that if using the inbuilt Database Manager.
Wappler only allows editing of a development target so targets would need to be switched back to their true values if database changes are needed or you will have to edit first into the production database (i assume you can then roll those changes backover to Development, never tried)
I think we can summarize the users with problems with the database updates to two groups having issues:
- Users that donāt use database manager to apply edits
- Users that do use it but havenāt applied all the changes due to errors
We can solve the issues for (1) we can check if there are any migration (changes) files in the database manager and if there are none we can leave out the whole apply db changes option.
For (2) we should first check if all changes are applied to the development database before trying to apply them to the remote live database to make sure we donāt get any errors there. So we should warn the user for unapplied changes first to either apply them or delete them.
So we will work on those solutions.
1 Like
@george, there are more reasons to improve the publish dialog that don't fit into the issues you mentioned.
Currently, I have to change the settings in the image below every time I publish.
This is a daily issue for me that adds many unnecessary clicks and has led to accidentally publishing to my Production environment since Wappler currently sets "Production" as the default value based on the Usage field in Project Options Targets.
Ideally, you could do something like:
- Add a tab in Project Options for "Publish" that allows us to
- Define what Target is the default in the "Publish To" field.
- Apply default settings (toggled/untoggled) for "Clear Unused Docker Image", "Apply Database Changes", and "Commit to Git".
For myself, I would set the defaults to this. This is also what I have to change in the above image nearly every time I publish.
@Hyperbytes, my workaround doesn't touch the local Development target and wouldn't be necessary if the above changes were made.
I'm only setting the Production target, as a non-production usage, so it doesn't show as the default option. It easily leads to incorrectly publishing to Production during frequent pushes to test/staging servers. Publishing to production should not be the default and require an extra step/action to avoid mistakes (i.e. having to manually change it to the production target in the menu or requiring a password). Similar to how delete actions typically require a confirmation dialog, but post and get actions do not.
@kfawcett it might be not very clear but the meaning of the whole "Publish" is to deploy to remote live targets.
For local development targets you don't have to use the publish - changes are automatically deployed when the local server is started and when files changes the local server is automatically restarted.
Also database changes are already applied to your local database server.
So again the Publishing is only needed for the remote live targets - that is why it defaults there to the remote production target.
And there you do need to apply database changes when you have those.
And if you really need to do local full redeploy (again only needed if some docker services has changed, otherwise it is done automatically), you can choose the docker options for the menu:
Deploy is needed when adding new packages in package.json file.
If Wappler adds new packages then an automatic npm install is run. If you add packages manually you can just click on " Install Node Packages" icon in the bottom toolbar to do it.
The command is smart enough to execute npm install within the docker container, so even then no full deploy is needed.
Yes, @george. I am talking about publishing to remote targets (test/staging/production), not local dev. I "publish" to test and staging targets more often than production.
Plus, I always want to clear unused docker images, so everytime I have to toggle it.
I don't normally need an extra step to apply database changes since there are none. So I untoggle it.
And I don't need to commit to git when I publish. So I have to untoggle it.
This has been improved in Wappler 7.2.0, the options you set will be remembered the next time you publish you project.
3 Likes