Deploying multiple modules using 'gcloud preview app deploy' - google-app-engine

I currently have an app containing two modules, each with its own version number. When I run 'gcloud preview app deploy module1/app.yaml module2/app.yaml' I get the following error:
One or more files have conflicting settings for the [version] field.
If these version numbers need to be the same, is there a way to separately version your modules or is this not supported?

So it looks like I should not be naming my module configuration files 'app.yaml' (a reserved name). By naming the files 'module1.yaml' and 'module2.yaml' the problem was resolved.

Related

Getting: Could not detect any platform in the source directory. for Deploying React on Azure Static site

Im deploying on azure static web app but getting the error, which says:
Could not detect any platform in the source directory.
Error: Could not detect the language from repo.
i tried changing the app_location to /src but still showing could not detect the language from repo.
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
app_location: "/src" # App source code path
api_location: "" # Api source code path - optional
output_location: "/build" # Built app content directory - optional
Glad #Bhanuvidh Mansinghani, that the given reference worked to resolve your issue.
I have found the similar issue from the GitHub of mslearn-staticwebapp repository that states could not detect the language from repository in static web app workflow.
Many customers faced the similar issue and fixed with the following steps:
Select the location and output folder for the application that is built for production environment and select custom option on step 5 instead of selecting the language.
Now, redeploy it after making the changes to existing one.
Also, check one of the workarounds given by the gcoines-uoc that to check the path of the application’s folder within the .yml file and had given the project folder structure based on hierarchy levels.

Exotic filetypes not loading after build in react

i created a create-react-app and want to use filetypes like webp or mp3.
When i run my application on localhost via npm run start everything works fine, but after my deployment on my server (which uses npm run build and delivers the build folder) it doesn't load filetypes like mp3 or webp anymore. Why is this happening? i think its any simple configuration in react or anything like that, but i cant solve this problem by my own. Thanks for your help.
The issue may be with typescript (if that is what you're using). Typescript will convert .ts and .tsx files to .js, but not move most other files over to build. If they are in a separate assets directory, you have to ensure that gets deployed too. If this is the issue, you have a few choices.
You can manually move the files over to build as a 'post' deploy step (using say, a shell script).
You can use a bundler like webpack to help you maintain the references to those other assets and bundle them correctly.
I finally found the problem that caused this behaviour. Amazon AWS Amplify creates a rewrite rule for single page applications (SPA). You can find this setting under Rewrites and redirects in your Amplify application settings. There you will find a rewrite rule with following source address:
</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>
...change it to...
</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json|mp3)$)([^.]+$)/>
... for example, to allow mp3 files. This is also important to allow webp-Images or woff2-Fonts.

Where to put Thorntail Swarm Configuration (project-defaults.yml) within a multi module Gradle project?

I'm trying to configure the Swarm AS based on Thorntail 2.5.0.Final with a project-defaults.yml within a multi-module Gradle project. Unfortunately the configuration file doesn't get picked up.
Where do I have to put the project-defaults.yml file so it's registered by Thorntail?
Currently the situation looks like this:
I think the sub module resources folder is not correct, because this configuration file should configure the whole AS, right?
The file belongs to src/main/resources. It seems you already have one there -- are the two different?
If you have a multi-module project, generally there should be one module that builds the uberjar, and that module should have src/main/resources/project-defaults.yml.

How can I read files outside src?

I understand that in react you cannot import files outside src folder.
But what is the reason for it exactly and can I disable it?
In my project react web app is only part of the whole thing, and different parts share some files (configs, build output), so folder structure looks like this
ProjectRoot/
config
build-output/
Part1/
Part2/
WebApp/
src/
...
Sure, you can copy files or create symlinks, but that's duplication and inconvenient.
This is a restriction of Create React App only.
This tool exists to get new users up and running with the react framework as fast as possible by abstracting away the tooling. The part of tooling that is limiting you in this instance is their webpack configuration, which is preset to only look for javascript files in your src directory.
That explains the why? but to answer the other half of your question:
how can I disable it?
Is that you would need to eject from Create React App and then modify your webpack config to allow it to search directories other than src/
First - this has nothing to do with react itself.
If you refer to importing javascript modules (for now using module loaders like systemjs, require, etc.) then the answer is:
It depends what directory is being served by web server. If you have set up your web server to serve WebApp/src folder only - then no, browser will not be able to get access to the files outside and so module loaders. If you will serve all ProjectRoot directory - then yes, you can.
If you prepare your web application for deployment using some sort of bundlers (webpack, browserify) - it depends on how you will configure them and instruct to include the required files in the resulting bundle.

Managing Demo / Full version of my app in Codename One

I was ordered to deliver an app in 2 versions : one demo/light (limitted features) the other full (all features). I have a boolean in code which tells which one is running. They both run as expected in the simulator or on a test device (iOS and Android).
Now I want to distribute them. So I read that it was possible with XCode to define different targets corresponding to the light / full versions and with Eclipse it was possible to define the base project as a library and then create 2 projects also corresponding to the light / full versions.
Before I start messing around with my app project, is there a recommended way to achieve my goal with CodenameOne maybe via build hints that would change the app name and the boolean inside the code depending on a build hint value ?
EDIT 19/09/2016 (working methodology)
Following Shai's advices here are the steps I followed to generate a light version based on the full one (in case someone encounters the same case) :
Under your IDE (Eclipse or whathever) copy and paste the base package in the src folder and rename it com.packageLIGHT.appName (simply append LIGHT to the package name, don't use underscore or space since it will be considered as an illegal character later by Apple)
=> So now in src folder you should have
src
|- com.packageLIGHT.appName
|- com.package.appName
Then in com.packageLIGHT.appName remove all files except MyApp.java (aka the main file). In this file add import com.package.myApp.*;
3.1. (ECLIPSE) In "Run/Run Configurations" menu copy the existing config and paste it as Simulator_MyAppLIGHT and in arguments change it to "com.packageLIGHT.myApp.MyApp".
3.2. (NETBEANS) The "Run/Set Project Configuration" does not seem to work as expected since any configuration that might be selected leads to the same default behaviour. However applying step 6. and running the project in the simulator afterward has the expected result.
Now you should be able to run both versions by running the different configurations.
For iOS (not sure if it is also needed for Android) you have to generate another pair of provisioning files. So move the existing ones in iosCerts/FULL and use CN1 wizard to generate the "light" version provisioning files where you'll adapt the package name to match "com.packageLIGHT.myApp". Store the generated files in iosCerts/LIGHT. There is no need to overwrite the existing certificates (more on certificate here).
Finally replace in "codenameone_settings.properties" the original package name with the "light" one for the lines codename1.ios.appid and codename1.packageName. Also change the iOS provisioning files to iosCerts/LIGHT or FULL depending of what you want to build.
Now when you send the Android / iOS build to CN1 server it will build either the "light" version or the full one depending on what package is written in "codenameone_settings.properties".
Please note : if at step 6. you get NullPointerException on build.xml on line 469 (android build) or 344 (iOS build) which deals with certPassword="${codename1.android.keystorePassword} (android build) or appid="${codename1.ios.appid}" (iOS build) and you're using CN1 plugin version 1.0.0 20160812 under Eclipse then Shai's comment below may be worth it
If you want 2 distinct versions of the same app then you need 2 distinct packages since the thing that defines the app uniquely in the store is the app package. There are two common ways to do it:
Place functionality in cn1lib and build two apps
Build one app and just swap the codenameone_settings.properties file
The first one should be pretty clear but might be a bit painful to work with as you can't run the cn1lib and might run into issues debugging it.
The second one is actually rather simple. Create the main version of the app then add the package to the demo version and copy the main file there.
To run the demo version just change the package in the IDE "run settings".
Copy your codenameone_settings.properties to a separate file and just replace all the regular package names to the demo package names. When you want to build the "demo" version replace the codenameone_settings.propeties files with one another, you can automate that with a script obviously.

Resources