I have been using mongo-driver in my project, deploying with gcloud app deploy for a while now. I recently rebuild my machine, and simply ran go get to get fetch ally my dependencies. Everything is compiling fine locally, however, gcloud app deploy fails:
Failed to build app: building app with command '[go build -o /tmp/staging/usr/local/bin/start ***\admin]', env '[PATH=/go/bin:/usr/local/go/bin:/builder/google-cloud-sdk/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=***HOME=/builder/home BUILDER_OUTPUT=/builder/outputs DEBIAN_FRONTEND=noninteractive GOROOT=/usr/local/go/ GOPATH=/go GOPATH=/tmp/staging/srv/gopath]': err=exit status 1, out=srv/gopath/src/go.mongodb.org/mongo-driver/x/mongo/driver/compression_cgo.go:15:2: cannot find package "github.com/DataDog/zstd" in any of:
/tmp/staging/srv/gopath/src/go.mongodb.org/mongo-driver/vendor/github.com/DataDog/zstd (vendor tree)
/usr/local/go/src/github.com/DataDog/zstd (from $GOROOT)
/tmp/staging/srv/gopath/src/github.com/DataDog/zstd (from $GOPATH).
Any ideas? app.yaml is just runtime: go113
Have you tried specifying dependencies with go mod yet?
I faced the same issue and finally can solved by generating go.mod file with these command,
GO111MODULE=on go mod init
GO111MODULE=on go mod tidy
Here is the details explanation.
Related
I'm new to jhipster. I am on jhipster v7.8.1, i can generate an app using the cli questions but when i try importing a jdl file i got the following error:
**ERROR! Class constructor GAstVisitor cannot be invoked without 'new'
TypeError: Class constructor GAstVisitor cannot be invoked without 'new'
at new DslMethodsCollectorVisitor
This occurs due to a recent bug in the one of JHipster libraries. As a temporary solution you can go to the JHipster installed location and find it's package.json file and override the package causing this error as follows. Then run npm install again.
"overrides":{
"chevrotain#10.1.2": {
"#chevrotain/gast": "10.1.2"
}
}
This will prevent the JHipster using latest package of that.
I experienced the same error and managed to get the JDL file to run by using version 7.8.1
I followed the following steps to get this done;
uninstall the current version of jhipster that is causing issues for
my case this was 7.9.2 . use this command npm uninstall -g
generator-jhipster
Install version 7.8.1 using this command npm
install -g generator-jhipster#7.8.1
Attempt to run your JDL using
this command jhipster jdl jhipster-jdl.jdl
At this stage, your JDL
will be able to run
I am currently learning haskell and just tried using postgresql as a database.
I generated my project with stack (stack new <name> -> stack setup -> stack build)
and then all I changed was adding the dependencies needed to persistent and postgresql to the
package.yaml file (under "dependencies:").
These are:
persistent
persistent-postgresql
persistent-template
This however results in a failing build with the following message:
postgresql-libpq > setup.exe: The program 'pg_config' is required but it could not be found.
postgresql-libpq >
-- While building package postgresql-libpq-0.9.4.2 using:
C:\Users\\AppData\Local\Temp\stack14388\postgresql-libpq-0.9.4.2.stack-work\dist\e626a42b\setup\setup --builddir=.stack-work\dist\e626a42b configure --user --package-db=clear --package-db=global --package-db=C:\sr\snapshots\365a3dde\pkgdb --libdir=C:\sr\snapshots\365a3dde\lib --bindir=C:\sr\snapshots\365a3dde\bin --datadir=C:\sr\snapshots\365a3dde\share --libexecdir=C:\sr\snapshots\365a3dde\libexec --sysconfdir=C:\sr\snapshots\365a3dde\etc --docdir=C:\sr\snapshots\365a3dde\doc\postgresql-libpq-0.9.4.2 --htmldir=C:\sr\snapshots\365a3dde\doc\postgresql-libpq-0.9.4.2 --haddockdir=C:\sr\snapshots\365a3dde\doc\postgresql-libpq-0.9.4.2 --dependency=Cabal=Cabal-2.4.1.0-5rQrtDcYhR2LOcYye7obEr --dependency=Win32=Win32-2.6.1.0 --dependency=base=base-4.12.0.0 --dependency=bytestring=bytestring-0.10.8.2 -f-use-pkg-config --extra-include-dirs=C:\Users\\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\include --extra-lib-dirs=C:\Users\\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\lib --extra-lib-dirs=C:\Users\\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\bin --exact-configuration --ghc-option=-fhide-source-paths
Process exited with code: ExitFailure 1
Does anyone know how to resolve this issue and why it even occurs?
Do I have to install postgresql just for being able to run build the project? If so, how would you
do this in production, when the database could basically lie everywhere?
It looks like Haskell is trying to build with the PostgreSQL client shared library libpq.dll and uses pg_config at build time to determine where PostgreSQL is installed and how it was built.
That would mean that you have to install PostgreSQL on the machine where you build Haskell, including the header files, build environment or however it is called by the installer.
For running Haskell you would only need libpq.dll and the dependent shared libraries.
I solved the issue in Ubuntu with the following command:
apt install libpq-dev
Context
We are trying to use edeliver to deploy a "Hot Upgrade" of a Phoenix Web Application to a remote Virtual Machine instance.
Our aim is to build an "upgrade" version of the app each time so that the app can be "hot" upgraded in production without any down-time.
We have succeeded in doing this "hot upgrade" on a "Hello World" phoenix app:
https://github.com/nelsonic/hello_world_edeliver which is automatically deployed from Travis-CI when the build passes. see: https://travis-ci.org/nelsonic/hello_world_edeliver/builds/259965752#L1752
So, in theory this technique should work for our "real" app.
Attempting to Deploy a "Real" Phoenix App using Edeliver
Ran the following command (to build the upgrade):
mix edeliver build upgrade --auto-version=git-revision --from=$(git rev-parse HEAD~) --to=$(git rev-parse HEAD) --verbose
i.e. "build the upgrade from the previous git revision to the current one"
So far, so good. "Release successfully built!"
Error: vm.args: No such file or directory
When we attempt to deploy the upgrade:
mix edeliver deploy upgrade to production --version=1.0.3+86d55eb --verbose
cat: /home/hladmin/healthlocker/releases/1.0.3+86d55eb/vm.args: No such file or directory
Note: we have a little bash script that reads the latest upgrade version available in .deliver/releases and deploys that see: version.sh
Question:
Is there a way to ignore the absence of the vm.args file and continue the deployment?
Or if the file is required to complete the deployment, is there some documentation on how to create the file?
Note: we have read the distillery "Runtime Configuration" docs: https://github.com/bitwalker/distillery/blob/master/docs/Runtime%20Configuration.md and are sadly none-the-wiser ...
Additional Info
Environment
Localhost: Mac running Elixir 1.4.2
Build Host: Ubuntu 16.04.2 LTS running Elixir 1.4.5
mix.exs file: https://github.com/healthlocker/healthlocker/blob/continuous-delivery/mix.exs
edeliver version: 1.4.4
Build tool: distillery version: 1.4.0
Umbrella project: yes.
This question was also asked on: https://github.com/edeliver/edeliver/issues/234
As mentioned by others, the vm.args file is necessary for BEAM to run the release. A default file is created by distillery during the release build process and should be located in releases/<version>/vm.args. From your log output it looks like expected directory is being checked.
Can you show us the contents of /home/hladmin/healthlocker/releases/?
Can you confirm that the default vm.args file is being created when building the release and extracting it (outside of the upgrade process)?
You also asked:
Or if the file is required to complete the deployment, is there some documentation on how to create the file?
If diagnosing the problem with the default vm.args file doesn't get you anywhere, you can also write your own file and configure distillery to use that file instead of the default. The details for this are in the distillery configuration docs. In short,
add the vm_args setting to your distillery config, which should be at rel/config.exs(relative to your project root), for example:
environment :prod do
set vm_args: "<path>/vm.args"
[...]
end
When running mix edeliver version production locally it fails with the following output
EDELIVER MYAPP WITH VERSION COMMAND
-----> getting release versions from production servers
production node:
user : app_user
host : my_app
path : /home/app_user/my_app.io
response: bash: line 4: bin/my_app: No such file or directory
bash: line 47: bin/my_app: No such file or directory
VERSION DONE!
The error is obvious, as the executable lives in: ~/my_app.io/my_app/_build/prod/rel/my_app/bin
I'm also unable to run any of the start/stop/restart etc commands
The deployment was successful because when I ssh in, and run the start command it works.
I would like to know if anyone can point me in the direction of some config parameter that I'm missing, as the local commands are a lot more efficient.
Figured out the problem
I only built my app by running the following: env MIX_ENV=prod mix edeliver build release
I was probably too excited and forgot to actually deploy the release using something similar to the following mix edeliver deploy release to production --version=0.0.1
Hope someone else might benefit from this also.
I wanted to implement Firebase SDK in my Swift project. I followed the instructions and installed pods, created a Podfile as follows:
platform :ios, '7.0'
target 'MyApp' do
pod 'Firebase'
project '/Users/MyName/Desktop/MyApp/MyApp.xcodeproj'
end
Then as I do install pods, it comes out with the following in terminal:
Analyzing dependencies
Downloading dependencies
Using Firebase (3.9.0)
Using FirebaseAnalytics (3.5.1)
Using FirebaseCore (3.4.4)
Using FirebaseInstanceID (1.0.8)
Using GoogleInterchangeUtilities (1.2.2)
Using GoogleSymbolUtilities (1.1.2)
Using GoogleToolboxForMac (2.1.0)
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There is 1 dependency from the Podfile and 7 total pods installed.
So I thought it worked but after reading various posts online apparently this is supposed to produce a xcworkspace file which I'm supposde to use instead of xcodeproj- is that correct? And if so why hasn't it generated it? I don't understand what is going wrong.
It might also be relevant info that I added all the bits to my xcodeproj file (before realising I should be working with xcworkspace instead) so the pods had come up in my xcodeproj, I added the import Firebase header file, the Google service info, plist and the import+ FIRApp.configure() in delegate and added $(inherited) in other linkers and when I try to use simulator it comes up with an error saying:
Library not found for GoogleToolBoxForMac
Linker command code failed with exit code 1 (use -v to see invocation).
How come it allowed me to do all this if the initial install was incorrect? And where do I go from here?
Can I please get some help about what is going wrong? And how can I solve this problem? Or at least am I able to go back to step one and reverse all these changes smoothly?
If possible please use examples, I am a newbie.
Incase someone else is having this error. The problem was that I was in the wrong directory and had attempted to put a Podfile with the directory leading to 'MyApp.xcodeproj'. This is incorrect as the Podfile should just be in the folder. Initially I was not able to locate this folder (even though it was on my Desktop) so I used in terminal:
cd ~/Desktop
then
cd ~/Desktop/MyApp
and then
pod init
and edited the Podfile followed by
pod install...