I am toying around a bit with GCP cloud shell editor which I start by visiting https://shell.cloud.google.com/?show=ide (which I installed as an PWA) and would like to debug a simple Flask AppEngine app. The app is using Cloud Logging. It runs fine in the terminal window when I first do:
gcloud config set project myproject
However if I want to use the builtin debugging I get errors because gcloud config set project myproject has not been set in that new window. So my question is how do I make sure that gcloud config set project myproject is run at startup of each console? I already tried running a preLaunchTask but since that is run in a separate console it does not help
Update (26 Jan 2021)
Also toyed around with trying to change the .bashrc automatically when opening a project by using a task that is triggered by folderOpen and then writes the relevant gcloud command to a script which is called by .bashrcas shown below
{
"version": "2.0.0",
"tasks": [
{
"label": "Set GCP Project",
"type": "shell",
"command": "echo \"set -x; gcloud config set project [MYPROJECT]\" > $HOME/set_gcp_project",
"runOptions": {
"runOn": "folderOpen"
},
"presentation": {
"reveal": "never",
"panel": "shared"
},
"problemMatcher": []
}
]
}
However Cloud Shell does not support these automated tasks. It works fine in VSCode. However it is still a nuisance because if in the GCP console I open a terminal or it opens it when you click on a run in cloud shell it sets the project to whatever project I had last opened in the Cloud Shell Editor
If you are interested in customizing your Cloud Shell experience you can always refer to the following section of the documentation.
I guess the must straightforward to always guarantee that the gcloud config set project myproject is always run when a new window is opened will be to append that gcloud command at the end of the .bashrc file located at your $HOME directory.
Just open the Cloud Shell (make sure you are located at the $HOME directory, which is the default directory that opens up when you open your Cloud Shell) and append the gcloud command by running the following command:
[YOUR-USERNAME]#cloudshell:~ (myproject)$ echo "gcloud config set project myproject" >> .bashrc
Related
I am new to FCM.
My function works great locally as a simple nodejs module but when i deploy it. The logs are showing that some files are not there. But I can't find instructions on how to inspect what exactly got deployed. This is the dist after running build (see post build below):
"build": "tsc",
"postbuild": "cp -r src/email/emails lib/email",
Here is my dist
Errors in my app say that /email/emails/html.pug do not exist or are not in the expected location. Could that have something to do with postbuild scripts? How am I expected to troubleshoot?
I have a meteor app that needs to periodically read a file located on the host's file system, outside of the app package. I am using node's fs to accomplish this, and it works fine on my (macOS) development machine.
However, when I run mup deploy to deploy it to my (Ubuntu 14) server, mup returns the following error after starting meteor:
Error: ENOENT: no such file or directory, open '/home/sam/data/all_data.json'
at Object.fs.openSync (fs.js:652:18)
at Object.fs.readFileSync (fs.js:553:33)
Does anyone know why this might be happening?
you should follow mup documentation closely. Have you seen volumes setup in mup config? Try this to solve your issue.
Reason: mup runs app in docker without any access to host file system unless specified. Volumes setup does this for you with mup deployment.
Below is the part of mup config from http://meteor-up.com/docs.html, Everything Configured, read more to get a better idea.
name: 'app',
path: '../app',
// lets you add docker volumes (optional). Can be used to
// store files between app deploys and restarts.
volumes: {
// passed as '-v /host/path:/container/path' to the docker run command
'/host/path': '/container/path',
'/second/host/path': '/second/container/path'
},
The user you have that is running your meteor build on the server needs to have access to that folder - read access. I would store the file in a different directory than the home one, because you don't want to mess it up. Either way doing something like chmod -R 444 /home/sam/data should give read access to any user for all files in that directory. You are probably running meteor as your local user(sam?) in development mode on your macOS, but the built up gets run as meteor or some other user on ubuntu, because of mup and forever.
For those who use Digital Ocean for hosting and mupx for deployment:
I can not successfully implement usage of settings.json file to run on deployment. Previously it caused failure of deployment, and now, for instance, when I tried to add the package okgrow:analytics, it doesn't work and this appear on browser console:
Missing analyticsSettings in Meteor.settings.public
although it is there.
{
"public": {
"analyticsSettings": {
"Google Analytics" : {
"trackingId": "xxxxxxx"
}
}
}
}
When running locally, one has to type meteor --settings settings.json to start the app. Is there something equivalent for the mupx? How can I configure accordingly?
Needless to say, I need settings.json for sensitive data which shall be ignored for git as well. Perhaps just meteor command should first check if settings.json exists, and accordingly run with the settings inside (if any). Then one doesn't need to type meteor --settings settings.json...
I realised my problem was due to having the settings.json file in the root of the project rather than within the mupx deploy folder.
It was sufficient, then, to just run mupx deploy
I'm trying to deploy a site to firebase.
firebase init worked fine. I then ran firebase bootstrap and chose the tetris template. So far so good. But when I run firebase deploy I get Preparing to deploy Public Directory... and then it just hangs forever.
How can I figure out what's going wrong?
Random info in case it helps:
My firebase-tools is version 1.0.1; node is version 0.8.20; npm is version 1.4.23. I ran sudo npm install -g firebase-tools to get the CLI. I'm running on a debian chroot on Android 4.4.3 device. My wifi works fine. On a lark I even tried running sudo firebase deploy in case it depends on ICMP packets or something, but there was no difference.
Firstly, the main reason it's not working is that Node.js version 0.10 or greater is required.
However, even once you've upgraded Node (and I'd recommend getting the latest of firebase-tools too) you're likely to be attempting to deploy the directory that you ran the initial firebase init command from, or at least the folder you specified in the setup (which defaults to the folder you ran the command from).
You should change directory and run the firebase deploy command from the folder that was created by the bootstrap command - which would have been named after the name of the Firebase it was created with, and you can delete the firebase.json file created in the parent directory.
The reason is that firebase init and firebase bootstrap are two different ways of doing the same thing - getting a folder in a deployable state. firebase init is for existing projects with files that will eventually be deployed, and firebase bootstrap is for creating a project from one of the existing templates. By running both, the initial firebase init would have created a firebase.json file containing the settings specified by the prompts, and then the firebase bootstrap command would have created a whole new sub-folder with its own firebase.json for the different settings.
How to deploy a app with password in meteor using linux. It's deploy good when with out set password.But i need to deploy app with password in meteor. I did but gets some error messages i didn't understand the following messages.So please see the below deployment process and suggestions me what to do?
[root#localhost myapp]# meteor deploy myapp.meteor.com --password
deploy: the --password option needs a value.
Try 'meteor help deploy' for help.
[root#localhost myapp]# meteor deploy myapp.meteor.com 123456
deploy: too many arguments.
Usage: meteor deploy <site> [--settings settings.json] [--debug] [--delete]
Deploys the project in your current directory to Meteor's servers.
You can deploy to any available name under 'meteor.com'
without any additional configuration, for example,
'myapp.meteor.com'. If you deploy to a custom domain, such as
'myapp.mydomain.com', then you'll also need to configure your domain's
DNS records. See the Meteor docs for details.
The --settings flag can be used to pass deploy-specific information to
the application. It will be available at runtime in Meteor.settings, but only
on the server. If the object contains a key named 'public', then
Meteor.settings.public will also be available on the client. The argument
is the name of a file containing the JSON data to use. The settings will
persist across deployments until you again specify a settings file. To
unset Meteor.settings, pass an empty settings file.
The --delete flag permanently removes a deployed application, including
all of its stored data.
Options:
--delete, -D permanently delete this deployment
--debug deploy in debug mode (don't minify, etc)
--settings set optional data for Meteor.settings
--star a star (tarball) to deploy instead of the current Meteor app
[root#localhost myapp]#
Perhaps you should use both command and option:
meteor deploy myapp.meteor.com --password 123456