I’m working on a Drupal project hosted on platform.sh.
I started to work locally with Lando but I messed things up a bit and I tried to create a second local Lando build for the same project to try some changes, keeping the fist project in it’s broken state.
The problem is that the second project seems to be using the same database as the first one.
This might be related to caching but I don’t wand to lose local database data from the first project and I’m not sure I can safely Lando pull to get fresh database data from platform.sh for the second project.
TL;DR - change the name property in the .lando.yml file in your second project.
Lando creates containers based on the name property you set up in your .lando.yml file (or .lando.upstream.yml if there's no .lando.yml file). If you created a second lando project but didnt change the name property, you end up using the same containers from the first project (which is what you're seeing). Stop lando in the second project (ie lando stop) and then change the name property in the .lando.yml file in the second project and then do lando start. Now lando should build new, separate containers for the second project based on the new name.
Related
When a nextjs app is deployed in a docker container, a new build wipes out the files from the previous build. In this case, when a client request a file from the previous build (because they have not refreshed the page and are using the files from the previous build), they could potentially get a runtime error because the file does not exist in the new container. What is the recommended approach to solve this problem?
Use cleanDistDir: false in next.config.js to preserve previous build files.
But you probably need to create your builds outside docker and pull / copy them into your docker container.
With an existing authserver and worldserver in Ubuntu 18.04, how can I add a second worldserver (realm) to their setup? Does it require a completely new CMAKE or can you just copy and paste the folders?
As you might have guessed, you need one worldserver process per every realm. So to add another realm, you need to run one more worldserver.
A worldserver needs:
its own acore_world database
its own acore_character database
the acore_auth will be shared across all realms, so you need only one of it
its own worldserver.conf file. Because of this, you have to recompile and pass a different path for the configuration file (so a different -DCMAKE_INSTALL_PREFIX)
Then you can open the new worldserver.conf and configure it with:
put a different port for WorldServerPort
the new databases (WorldDatabaseInfo and CharacterDatabaseInfo)
and of course, you can change other configurations as you please
If I remember correctly, you can set your worldserver.conf A and worldserver.conf B to share the same data files (DataDir - tip: always put an absolute path here).
Lastly, you have to update your acore_auth.realmlist table by adding the new realm and its port.
I have a database project and want to keep a table as a backup on the production database but it shouldn't be part of the code anymore.
Even if I rename the table before generating the deployment script the rename is detected (via a search for named constraints I guess) and the renamed table will be dropped.
Any ideas on that?
It's a bit of a workaround, but if the goal is to prevent this table from being created on new deployments (where it doesn't already exist), but keep it on deployments where it's already been added, then you could keep it in the code and add a post-deploy script to delete it if it doesn't contain any data.
Or you could write your own "plugin" for the database deployment Customize Database Build and Deployment by Using Build and Deployment Contributors
One of our projects consists of multiple simple Orchestrations. Whenever I deploy the Orchestrations in an msi from the Dev to live environment, the bindings on 2 of them change (The msi has no bindings in it). These Orchestrations have 2 send-ports, one to live and one to a backup location.
So far, in both cases where the send-Port has a changed binding it has been the backup send-port that suddenly changes and the send-ports that change have been consistent. out of a total of 12 ports on 6 Orchestrations in this one project, it is always the same two that change.
But why do they change? And why does it seem to be in a way that makes no sense? The send-ports on Dev have unrelated quickly named send-ports that couldn't change the ones on live. The only thing I can think of is that the initial configuration was wrong and that every new installation of the msi resets the Orchestration to this initial configuration.
Development settings
Live settings before install of MSI
Live settings after install of MSI
Have a look in the folder %APPDATA%\Microsoft\BizTalk Server\Deployment\BindingFiles\
You will find that there will be some binding files in there including one that contains your bad configuration. Delete all the files in that folder and with the next deployment it will re-create it with the latest binding configuration. It seems that BizTalk takes a copy of the binding to re-apply after a MSI is deployed, however it seems to have a bug and sometimes doesn't detect that it has changed and does not re-export the binding to that cache and so ends up using a old copy.
Best practice is actually to apply the bindings you want after every deployment and that these bindings are under source control.
I am using MSBuild to Publish a web site, then copy the published site to a web server on the same network. I set the copy command to "SkipUnchangedFiles."
It works swimmingly, but Skip Unchanged won't work because when I use AspNetCompiler to publish the website, each and every file is "new" -- its date is set to the moment of publishing, so even if the contents of a given file have not changed, the timestamp is different, so it's copied over anyway.
Is there a workaround that will prevent file whose contents have not changed from being copied?
Depending on how you're publishing the site, you may be able to do Incremental Build instead of a full build.
There is no existing process for this as the deployment process isn't aware of the deployment target filesystem.
If you were aware you could do a diff using a tool like beyond compare and then grab only the binary diff'ed items and copy those across.
Looking to automate this you are probably going to have to dig into writing msbuild targets or post build scripts.