I try to publish a program to a gitlab-server, via electron-builder. This is my electron-config.yml file:
appId: ch.janisperren.arawexdashboard
publish:
provider: github
token: mytoken
host: gitlab.myserver.ch
owner: myname
repo: myrepo
asar: true
files:
- "app.js"
- "dist/myfiles/*"
linux:
target:
target: AppImage
arch: x64
The app is being generated, but it is not published to the repo. I always get following error message:
API V3 is no longer supported. Use API V4 instead
But I don't know how to force the electron-builder in using the API V4. Any suggestions?
Thanks!
Related
Recently I upgraded various packages (nextJS and Apollo) and so had to upgrade my version of node to 16.13.1 as required. I am using a github build workflow and specify the node version to be 16.13.1. When it is finished building it deploys but I get 500 errors when an api call tries to hit apollo. I suspect my apollo server is not building. When I look at the console logs I can see an error wrt to optional chaining which i suspect is stopping the apollo server from building properly hence causing the 500 runtime errors when it tries to be queried. Optional chaining should be working on this version of node and it does when running locally so why not when deployed?
Any debugging recommendations? I think pursuing the problem code below is a red herring fyi
Error copied from console:
2023-01-17T11:45:58.249754172Z /home/site/wwwroot/.next/server/pages/api/graphql.js:5515
2023-01-17T11:45:58.249791573Z if (!response?.record) return null;
2023-01-17T11:45:58.249796773Z ^
2023-01-17T11:45:58.249800473Z
2023-01-17T11:45:58.249803973Z SyntaxError: Unexpected token '.'
2023-01-17T11:45:58.249807573Z at wrapSafe (internal/modules/cjs/loader.js:915:16)
2023-01-17T11:45:58.249811173Z at Module._compile (internal/modules/cjs/loader.js:963:27)
2023-01-17T11:45:58.249814773Z at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
Workflow file (only showing node and build steps)
on:
push:
branches:
- test
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- uses: actions/cache#v1
with:
path: ${{ github.workspace }}/.next/cache
key: ${{ runner.os }}-nextjs-${{ hashFiles('**/yarn.lock') }}
- name: Set up Node.js version
uses: actions/setup-node#main
with:
node-version: '16.13.1'
- name: npm install, build, and test
run: |
npm install
npm run build
npm run lint:eslint
npm run test:ci
tried altering the version of node and syntax. Used node-version '16', '14', '12.x', '16.x'.
tried to use different actions/setup-node versions inc 'v1', 'v2' 'v3'.
tried to build without the caching step (actions/cache#v1 with .....etc) - this actually results in an Internal Server Error failure when deployed and my wider nextjs app pages seem to fail as well. console logs seems to suggest issues with 'nullish coalescing operator' is the cause in this case.
I found out that the container I am hosting my app within has a Target Framework configuration setting that is set to node 12. When I updated this to node 16 the build worked.
See post here for changing configuration in Azure App Service: Changing the target framework in an Azure web app
In summary the app was built successfully in node 16 and deployed to the app service as a node 16 app but whatever the container was doing it was doing it in node 12 and so complained about syntax that was not available in node 12 eg optional chaining and nullish coalescing.
I am not sure if this setup is only specific to Azure so hopefully this can help someone as at least a check to perform if you face a similar issue.
I have a nodejs serverless project that has this structure:
-node_modules
-package.json
-serverless.yml
-funcitons
-medium
-mediumHandler.js
my serverless.yml:
service: googleAnalytic
provider:
name: aws
runtime: nodejs6.10
stage: dev
region: us-east-1
package:
include:
- node_modules/**
functions:
mediumHandler:
handler: functions/medium/mediumHandler.mediumHandler
events:
- schedule:
name: MediumSourceData
description: 'Captures data between set dates'
rate: rate(2 minutes)
- cloudwatchEvent:
event:
source:
- "Lambda"
detail-type:
- ""
- cloudwatchLog: '/aws/lambda/mediumHandler'
my sls info shows:
Service Information
service: googleAnalytic
stage: dev
region: us-east-1
stack: googleAnalytic-dev
api keys:
None
endpoints:
None
functions:
mediumHandler: googleAnalytic-dev-mediumHandler
When I run sls:
serverless invoke local -f mediumHandler
it works and my script where I included googleapis and aws-sdk work. But when I deploy, those functions are skipped and show no error.
When debugging serverless's packaging process, use sls package (or sls deploy --noDeploy (for old versions). You'll get a .serverless directory that you can inspect to see what's inside the deployment package.
From there, you can see if node_modules is included or not and make changes to your serverless.yml correspondingly without needing to deploy every time you make a change.
Serverless will exclude development packages by default. Check your package.json and ensure your required packages are in the dependencies object, as devDependencies will be excluded.
I was dumb to put this in my serverless.yml which caused me the same issue you're facing.
package:
patterns:
- '!node_modules/**'
I am trying to deploy a node.js app to appEngine but he doesn't seem to like my app.yaml.
D:\projects\Personal\Project>gcloud app deploy
ERROR: (gcloud.app.deploy) An error occurred while parsing file: [D:\projects\Personal\Project\app.yaml]
No URLMap entries found in application configuration
in "D:\projects\Personal\Project\app.yaml", line 10, column 12
Here's the app.yaml:
runtime: nodejs
env: standard
skip_files:
- ^node_modules$
env_variables:
USER: 'dbUser'
PASSWORD: 'DBPass'
DB: 'URI to DB'
Am I missing something here?
Could it be that it's because of my folder structure?
I have following structure:
- client
- server
---- server.js
- app.yaml
So the app.yaml is not in the server folder as otherwise it doesn't include the client folder...
Now that nodejs8 is supported in the standard environment (still in beta at this time), you must update your local gcloud environment to be able to deploy. Updating your gcloud components will make this warning go away.
Run
gcloud components update
Update your app.yaml file
See Google's github for the most basic example required: https://github.com/GoogleCloudPlatform/nodejs-docs-samples/blob/master/appengine/building-an-app/build/app.yaml
Update your package.json
Specify the appropriate compatible node version, example:
"engines": {
"node": ">=8.0.0"
},
Full Tutorial
On building a nodejs8 app in the App Engine standard environment: https://cloud.google.com/appengine/docs/standard/nodejs/building-app/
The standard environment deploys significantly faster than the flex environment.
There is no standart environment with nodejs in AppEngine.
You must use env: flex.
see this.
When package is being deployed to npm registry, some weird additional messages appear on Travis CI console:
Standard messages:
Deploying application
NPM API key format changed recently. If your deployment fails, check your API key in ~/.npmrc.
http://docs.travis-ci.com/user/deployment/npm/
~/.npmrc size: 48
+ my-package#1.0.0
Then weird messages follow:
Already up-to-date!
Not currently on any branch.
nothing to commit, working tree clean
Dropped refs/stash#{0} (bff3fdd...1c6d37a)
.travis.yml file:
dist: trusty
sudo: required
env:
- CXX="g++-4.8"
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- g++-4.8
language: node_js
node_js:
- 5
- 6
- 7
deploy:
provider: npm
email: me#me.xx
api_key:
secure: ja...w=
on:
tags: true
branch: master
How to get rid of these messages, and also why are they there?
Cheers!
Deploying azure function using appveyor is straightforward as described by this article - https://alastairchristian.com/deploying-azure-functions-from-appveyor-75fe03771d0c#.x7stvprna
Further what I am not able to figure out is how to deploy a custom dll (library part of the same repo) in the /bin folder to be able to use #r and use the reference.
Manual process is just to copy the dll in the /bin folder using Kudu and start using it.
Also refer to this discussion on appveyor - http://help.appveyor.com/discussions/questions/2842-deployment-to-azure-function-app
Here is my appveyor.yml -
-
branches:
only:
- master
version: 0.0.{build}
os: Visual Studio 2015
configuration: Release
init:
- nuget sources update -Name nuget.org -Source https://api.nuget.org/v3/index.json
environment:
SolutionDir: $(APPVEYOR_BUILD_FOLDER)\
cache:
- packages -> **\packages.config
assembly_info:
patch: true
file: '**\AssemblyInfo.*'
assembly_version: '{version}'
assembly_file_version: '{version}'
assembly_informational_version: '{version}'
before_build:
- nuget restore -verbosity detailed
build:
verbosity: normal
project: MyLibrary\MyLibrary.csproj
publish_wap: true
publish_azure: true
parallel: true
artifacts:
- path: AzureFuncCIPOC
name: AzureFuncCIPOC
deploy:
- provider: WebDeploy
server: https://functioncipoc.scm.azurewebsites.net:443/msdeploy.axd?site=FunctionCIPOC
website: FunctionCIPOC
username: $FunctionCIPOC
password:
secure: <secure>
artifact: AzureFuncCIPOC
If your build process is building that library and moving the output (your custom DLL) so that is is packaged in the artifact created by AppVeyor, it will be deployed with the scripts.
I was able to copy the required dlls as project post-build event and then use the same .yml as posted in question to achieve what I was after. Really hope that VS 2017 will have better support for this when Azure Functions tools for VS2017 are launched.
below is the post-build event command
if not exist "$(SolutionDir)AzureFuncCIPOC\\ManualTriggerCSharp\bin\" mkdir "$(SolutionDir)AzureFuncCIPOC\\ManualTriggerCSharp\bin\"
copy /y "$(TargetDir)" "$(SolutionDir)AzureFuncCIPOC\\ManualTriggerCSharp\bin\"