I was installing Node.js on Windows. It installed successfully, and I also selected the option to install necessary files (such as chocolatey) in the node.js installer. After node was installed, it opened up Powershell; after installing for a while, I got this error:
# A lot of logs before, just an excerpt
Microsoft.VisualStudio.Workload.VCTools Microsoft.VisualStudio.Component.Roslyn.Compiler Microsoft.Component.MSBuild Microsoft.VisualStudio.Component.CoreBuildTools Microsoft.VisualStudio.Component.Windows10SDK Microsoft.VisualStudio.Component.VC.CoreBuildTools Microsoft.VisualStudio.Component.Static.Analysis.Tools Microsoft.VisualStudio.Component.VC.Tools.x86.x64 Microsoft.VisualStudio.Component.VC.Redist.14.Latest Microsoft.VisualStudio.Component.Windows10SDK.17763 Microsoft.VisualStudio.Component.VC.CMake.Project Microsoft.VisualStudio.Component.TestTools.BuildTools
[5330:000f][2021-04-19T18:24:09] Decorating UnelevatedProductModifier with UnelevatedInstallerTelemetryDecorator
[5330:000f][2021-04-19T18:24:09] Created a UnelevatedInstallerTelemetryDecorator
[5330:000e][2021-04-19T18:24:09] Download requested: https://aka.ms/vs/15/release/channel
[5330:001d][2021-04-19T18:24:09] Attempting download 'https://aka.ms/vs/15/release/channel' using engine 'WebClient'
[5330:001d][2021-04-19T18:24:09] WebClient error 'RequestCanceled' with 'https://aka.ms/vs/15/release/channel' - GetWebResponse failed along with a cancellation request
[5330:001d][2021-04-19T18:24:09] Error 0x8013153b: [5330:001d][2021-04-19T18:24:09] Could not update channel "https://aka.ms/vs/15/release/channel"
at System.Threading.CancellationToken.ThrowOperationCanceledException()
at System.Threading.CancellationToken.ThrowIfCancellationRequested()
at Microsoft.VisualStudio.Setup.Download.WebClientEngine.GetWebResponse(Uri uri, DownloadContext downloadContext, DownloadSummary& downloadSummary, HttpWebRequest& webRequest, CancellationToken cancellationToken)
at Microsoft.VisualStudio.Setup.Download.WebClientEngine.DownloadCore(Uri uri, Stream stream, ProgressUpdateCallback progress, CancellationToken cancellationToken, DownloadContext downloadContext, ITelemetryOperation telemetryOperation)
at Microsoft.VisualStudio.Setup.Download.DownloadEngineBase.DownloadWithBitRate(Uri uri, Stream outputStream, ProgressUpdateCallback progress, CancellationToken cancellationToken, DownloadContext downloadContext, ITelemetryOperation telemetryOperation)
at Microsoft.VisualStudio.Setup.Download.DownloadEngineBase.Download(Uri uri, Stream outputStream, ProgressUpdateCallback progress, CancellationToken cancellationToken, DownloadContext downloadContext, ITelemetryOperation telemetryOperation)
at Microsoft.VisualStudio.Setup.Download.DownloadManager.DownloadWithRetry(IDownloadEngine[] engines, Uri uri, Stream outputStream, ProgressUpdateCallback progress, CancellationToken cancellationToken, DownloadContext downloadContext, Boolean verifySignature)
at Microsoft.VisualStudio.Setup.Download.DownloadManager.<>c__DisplayClass23_0.<Download>b__0()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Setup.ChannelManager.<GetLatestChannelManifestAsync>d__85.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Setup.ChannelManager.<UpdateChannelManifestAsync>d__77.MoveNext()
And nothing else is happening. What do I do?
The additional tools install a number of items and their dependencies as mentioned when progressing through the script. These items would be used in case any node modules need to be compiled with these tools.
This script will install Python and the Visual Studio Build Tools, necessary
to compile Node.js native modules. Note that Chocolatey and required Windows
updates will also be installed.
This will require about 3 Gb of free disk space, plus any space necessary to
install Windows updates. This will take a while to run.
Example for node-v16.13.0-x64.msi
- https://chocolatey.org/packages/chocolatey
- https://chocolatey.org/packages/python
- https://chocolatey.org/packages/visualstudio2019-workload-vctools
In particular the visualstudio2019-workload-vctools involves the download of 1.6 gig of build tools, which can take awhile.
If you are wondering if things are progressing, try to launch Visual Studio Installer. If it is still running, you might get a message that says "Cannot start another instance of the installer while this instance is running."
If you've exited, rebooted, and relaunched the script and you're still wondering if all the tools got installed you can do the following:
Type choco list -lo to see if the packages visualstudio-installer, visualstudio2019-workload-vctools, and visualstudio2019buildtools are installed
open the Visual Studio Installer and you can see if the installer has completed installing the build tools. It may need to be resumed.
Same problem today. I just had Windows Powershell stop and freeze for about 5 minutes while installing Node.JS for VS Code (not Visual Studio). Last output from console is:
$ Created a UnelevatedInstallerTelemetryDecorator
Long story short: I had to exit the terminal (did not like this action) and reboot the computer because the install program was still running. Then I clicked on the installation file to run the Node.js Setup Wizard (node-v15.14.0-x64.msi). There is a second option to repair the install attempt: "Repair". Click on that button and the install wizard completes the repair with full exit. The program notices that some elements have not been completed. Then you can run a javascript file at the terminal in VS Code.
I did not have to repair VS Code.
Sample run from VS Code Terminal (terminal entry in bold)
PS "Drive Location"\JavaScript> node canDrinkNoIfs.js
To run the script in VSC I need to open the folder (File -> open folder.) and then create a json file to run and debug code. This json file is saved the .vscode subfolder.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "pwa-node",
"request": "launch",
"name": "Launch Program",
"skipFiles": [
"<node_internals>/**"
],
"program": "${workspaceFolder}\\canDrinkNoifs.js"
}]}
it happens to me.
first try to use space or tab. in my first stop powershell
Download of vs_BuildTools.exe (1.4 MB) completed.
Hashes match.
Installing visualstudio2017buildtools...
is working...
guys if you use space or tab, and then work: this happens because you use the click-mouse in the PowerShell, don't do this, sometimes is pausing the program :) [if is working, is a normal error, and it don't cause nothing danger for completing the downloading]
but then I have a lot of white text.
the last stop is
[1968:0007][2021-08-24T19:47:57] Created a UnelevatedInstallerTelemetryDecorator
here the error you have.❌
for correct this error... do this!
go to edge (or the browser you choose for download)
go to download tab, where there is node-v14.17.5-x64.msi (for edge is CTRL+J)
OPEN FILE
CLICK REPAIR
and that's it
i will put some photos of final result if you need it:
final result SUCCESS✅
EDIT
After a while i have this, in the same powershell i have the first stop.
Chocolatey timed out waiting for the command to finish. The timeout
specified (or the default value) was '2700' seconds. Perhaps try a
higher `--execution-timeout`? See `choco -h` for details.
visualstudio2017-workload-vctools may be able to be automatically uninstalled.
The upgrade of visualstudio2017-workload-vctools was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\visualstudio2017-workload-vctools\tools\ChocolateyInstall.ps1'.
See log for details.
Chocolatey upgraded 15/17 packages. 2 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Upgraded:
- chocolatey-dotnetfx.extension v1.0.1
- kb3033929 v1.0.5
- visualstudio2017buildtools v15.9.38.0
- chocolatey-windowsupdate.extension v1.0.4
- vcredist140 v14.29.30133
- kb2999226 v1.0.20181019
- visualstudio-installer v2.0.1
- kb2919355 v1.0.20160915
- chocolatey-core.extension v1.3.5.1
- kb2919442 v1.0.20160915
- chocolatey-visualstudio.extension v1.9.0
- vcredist2015 v14.0.24215.20170201
- dotnetfx v4.8.0.20190930
- kb3035131 v1.0.3
- python v3.9.6
Failures
- python3 (exited 1603) - Error while running 'C:\ProgramData\chocolatey\lib\python3\tools\chocolateyInstall.ps1'.
See log for details.
- visualstudio2017-workload-vctools (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\visualstudio2017-workload-vctools\tools\ChocolateyInstall.ps1'.
See log for details.
and the last thing is TYPE ENTER FOR EXIT - message on powershell
if you see the last message.
See "choco -h" for details.
so, i write it, in PowerShell.
i have this result, with a green message, in the end, with the version
This is a listing of all of the different things you can pass to choco.
Commands
* list - lists remote or local packages
* find - searches remote or local packages (alias for search)
* search - searches remote or local packages (alias for list)
* info - retrieves package information. Shorthand for choco search pkgname --exact --verbose
* install - installs packages from various sources
* pin - suppress upgrades for a package
* outdated - retrieves packages that are outdated. Similar to upgrade all --noop
* upgrade - upgrades packages from various sources
* uninstall - uninstalls a package
* pack - packages up a nuspec to a compiled nupkg
* push - pushes a compiled nupkg
* new - generates files necessary for a chocolatey package from a template
* sources - view and configure default sources (alias for source)
* source - view and configure default sources
* config - Retrieve and configure config file settings
* feature - view and configure choco features
* features - view and configure choco features (alias for feature)
* setapikey - retrieves, saves or deletes an apikey for a particular source (alias for apikey)
* apikey - retrieves, saves or deletes an apikey for a particular source
* unpackself - have chocolatey set itself up
* version - [DEPRECATED] will be removed in v1 - use `choco outdated` or `cup <pkg|all> -whatif` instead
* update - [DEPRECATED] RESERVED for future use (you are looking for upgrade, these are not the droids you are looking for)
Please run chocolatey with `choco command -help` for specific help on
each command.
How To Pass Options / Switches
You can pass options and switches in the following ways:
* Unless stated otherwise, an option/switch should only be passed one
time. Otherwise you may find weird/non-supported behavior.
* `-`, `/`, or `--` (one character switches should not use `--`)
* **Option Bundling / Bundled Options**: One character switches can be
bundled. e.g. `-d` (debug), `-f` (force), `-v` (verbose), and `-y`
(confirm yes) can be bundled as `-dfvy`.
* NOTE: If `debug` or `verbose` are bundled with local options
(not the global ones above), some logging may not show up until after
the local options are parsed.
* **Use Equals**: You can also include or not include an equals sign
`=` between options and values.
* **Quote Values**: When you need to quote an entire argument, such as
when using spaces, please use a combination of double quotes and
apostrophes (`"'value'"`). In cmd.exe you can just use double quotes
(`"value"`) but in powershell.exe you should use backticks
(`` `"value`" ``) or apostrophes (`'value'`). Using the combination
allows for both shells to work without issue, except for when the next
section applies.
* **Pass quotes in arguments**: When you need to pass quoted values to
to something like a native installer, you are in for a world of fun. In
cmd.exe you must pass it like this: `-ia "/yo=""Spaces spaces"""`. In
PowerShell.exe, you must pass it like this: `-ia '/yo=""Spaces spaces""'`.
No other combination will work. In PowerShell.exe if you are on version
v3+, you can try `--%` before `-ia` to just pass the args through as is,
which means it should not require any special workarounds.
* **Periods in PowerShell**: If you need to pass a period as part of a
value or a path, PowerShell doesn't always handle it well. Please
quote those values using "Quote Values" section above.
* Options and switches apply to all items passed, so if you are
installing multiple packages, and you use `--version=1.0.0`, choco
is going to look for and try to install version 1.0.0 of every
package passed. So please split out multiple package calls when
wanting to pass specific options.
Scripting / Integration - Best Practices / Style Guide
When writing scripts, such as PowerShell scripts passing options and
switches, there are some best practices to follow to ensure that you
don't run into issues later. This also applies to integrations that
are calling Chocolatey and parsing output. Chocolatey **uses**
PowerShell, but it is an exe, so it cannot return PowerShell objects.
Following these practices ensures both readability of your scripts AND
compatibility across different versions and editions of Chocolatey.
Following this guide will ensure your experience is not frustrating
based on choco not receiving things you think you are passing to it.
* For consistency, always use `choco`, not `choco.exe`. Never use
shortcut commands like `cinst` or `cup`.
* Always have the command as the first argument to `choco. e.g.
`choco install`, where `install` is the command.
* If there is a subcommand, ensure that is the second argument. e.g.
`choco source list`, where `source` is the command and `list` is the
subcommand.
* Typically the subject comes next. If installing packages, the
subject would be the package names, e.g. `choco install pkg1 pkg2`.
* Never use 'nupkg' or point directly to a nupkg file UNLESS using
'choco push'. Use the source folder instead, e.g. `choco install
<package id> --source="'c:\folder\with\package'"` instead of
`choco install DoNotDoThis.1.0.nupkg` or `choco install DoNotDoThis
--source="'c:\folder\with\package\DoNotDoThis.1.0.nupkg'"`.
* Switches and parameters are called simply options. Options come
after the subject. e.g. `choco install pkg1 --debug --verbose`.
* Never use the force option (`--force`/`-f`) in scripts (or really
otherwise as a default mode of use). Force is an override on
Chocolatey behavior. If you are wondering why Chocolatey isn't doing
something like the documentation says it should, it's likely because
you are using force. Stop.
* Always use full option name. If the short option is `-n`, and the
full option is `--name`, use `--name`. The only acceptable short
option for use in scripts is `-y`. Find option names in help docs
online or through `choco -?` /`choco [Command Name] -?`.
* For scripts that are running automated, always use `-y`. Do note
that even with `-y` passed, some things / state issues detected will
temporarily stop for input - the key here is temporarily. They will
continue without requiring any action after the temporary timeout
(typically 30 seconds).
* Full option names are prepended with two dashes, e.g. `--` or
`--debug --verbose --ignore-proxy`.
* When setting a value to an option, always put an equals (`=`)
between the name and the setting, e.g. `--source="'local'"`.
* When setting a value to an option, always surround the value
properly with double quotes bookending apostrophes, e.g.
`--source="'internal_server'"`.
* If you are building PowerShell scripts, you can most likely just
simply use apostrophes surrounding option values, e.g.
`--source='internal_server'`.
* Prefer upgrade to install in scripts. You can't `install` to a newer
version of something, but you can `choco upgrade` which will do both
upgrade or install (unless switched off explicitly).
* If you are sharing the script with others, pass `--source` to be
explicit about where the package is coming from. Use full link and
not source name ('https://chocolatey.org/api/v2' versus
'chocolatey').
* If parsing output, you might want to use `--limit-output`/`-r` to
get output in a more machine parseable format. NOTE: Not all
commands handle return of information in an easily digestible
output.
* Use exit codes to determine status. Chocolatey exits with 0 when
everything worked appropriately and other exits codes like 1 when
things error. There are package specific exit codes that are
recommended to be used and reboot indicating exit codes as well. To
check exit code when using PowerShell, immediately call
`$exitCode = $LASTEXITCODE` to get the value choco exited with.
Here's an example following bad practices (line breaks added for
readability):
`choco install pkg1 -y -params '/Option:Value /Option2:value with
spaces' --c4b-option 'Yaass' --option-that-is-new 'dude upgrade'`
Now here is that example written with best practices (again line
breaks added for readability - there are not line continuations
for choco):
`choco upgrade pkg1 -y --source="'https://chocolatey.org/api/v2'"
--package-parameters="'/Option:Value /Option2:value with spaces'"
--c4b-option="'Yaass'" --option-that-is-new="'dude upgrade'"`
Note the differences between the two:
* Which is more self-documenting?
* Which will allow for the newest version of something installed or
upgraded to (which allows for more environmental consistency on
packages and versions)?
* Which may throw an error on a badly passed option?
* Which will throw errors on unknown option values? See explanation
below.
Chocolatey ignores options it doesn't understand, but it can only
ignore option values if they are tied to the option with an
equals sign ('='). Note those last two options in the examples above?
If you roll off of a commercial edition or someone with older version
attempts to run the badly crafted script `--c4b-option 'Yaass'
--option-that-is-new 'dude upgrade'`, they are likely to see errors on
'Yaass' and 'dude upgrade' because they are not explicitly tied to the
option they are written after. Now compare that to the other script.
Choco will ignore `--c4b-option="'Yaass'"` and
`--option-that-is-new="'dude upgrade'"` as a whole when it doesn't
register the options. This means that your script doesn't error.
Following these scripting best practices will ensure your scripts work
everywhere they are used and with newer versions of Chocolatey.
Default Options and Switches
-?, --help, -h
Prints out the help menu.
-d, --debug
Debug - Show debug messaging.
-v, --verbose
Verbose - Show verbose messaging. Very verbose messaging, avoid using
under normal circumstances.
--trace
Trace - Show trace messaging. Very, very verbose trace messaging. Avoid
except when needing super low-level .NET Framework debugging. Available
in 0.10.4+.
--nocolor, --no-color
No Color - Do not show colorization in logging output. This overrides
the feature 'logWithoutColor', set to 'False'. Available in 0.10.9+.
--acceptlicense, --accept-license
AcceptLicense - Accept license dialogs automatically. Reserved for
future use.
-y, --yes, --confirm
Confirm all prompts - Chooses affirmative answer instead of prompting.
Implies --accept-license
-f, --force
Force - force the behavior. Do not use force during normal operation -
it subverts some of the smart behavior for commands.
--noop, --whatif, --what-if
NoOp / WhatIf - Don't actually do anything.
-r, --limitoutput, --limit-output
LimitOutput - Limit the output to essential information
--timeout, --execution-timeout=VALUE
CommandExecutionTimeout (in seconds) - The time to allow a command to
finish before timing out. Overrides the default execution timeout in the
configuration of 2700 seconds. '0' for infinite starting in 0.10.4.
-c, --cache, --cachelocation, --cache-location=VALUE
CacheLocation - Location for download cache, defaults to %TEMP% or value
in chocolatey.config file.
--allowunofficial, --allow-unofficial, --allowunofficialbuild, --allow-unofficial-build
AllowUnofficialBuild - When not using the official build you must set
this flag for choco to continue.
--failstderr, --failonstderr, --fail-on-stderr, --fail-on-standard-error, --fail-on-error-output
FailOnStandardError - Fail on standard error output (stderr), typically
received when running external commands during install providers. This
overrides the feature failOnStandardError.
--use-system-powershell
UseSystemPowerShell - Execute PowerShell using an external process
instead of the built-in PowerShell host. Should only be used when
internal host is failing. Available in 0.9.10+.
--no-progress
Do Not Show Progress - Do not show download progress percentages.
Available in 0.10.4+.
--proxy=VALUE
Proxy Location - Explicit proxy location. Overrides the default proxy
location of ''. Available for config settings in 0.9.9.9+, this CLI
option available in 0.10.4+.
--proxy-user=VALUE
Proxy User Name - Explicit proxy user (optional). Requires explicity
proxy (`--proxy` or config setting). Overrides the default proxy user of
''. Available for config settings in 0.9.9.9+, this CLI option available
in 0.10.4+.
--proxy-password=VALUE
Proxy Password - Explicit proxy password (optional) to be used with
username. Requires explicity proxy (`--proxy` or config setting) and
user name. Overrides the default proxy password (encrypted in settings
if set). Available for config settings in 0.9.9.9+, this CLI option
available in 0.10.4+.
--proxy-bypass-list=VALUE
ProxyBypassList - Comma separated list of regex locations to bypass on
proxy. Requires explicity proxy (`--proxy` or config setting). Overrides
the default proxy bypass list of ''. Available in 0.10.4+.
--proxy-bypass-on-local
Proxy Bypass On Local - Bypass proxy for local connections. Requires
explicity proxy (`--proxy` or config setting). Overrides the default
proxy bypass on local setting of 'True'. Available in 0.10.4+.
--log-file=VALUE
Log File to output to in addition to regular loggers. Available in 0.1-
0.8+.
Chocolatey v0.10.15
the most important thing is:
`Chocolatey v0.10.15`
chocolatey v.0.10.15 message
ok, let test if npm is installed :)
first at all write: npm -version
if return a version, you are fine!!!! 😊
now you can install from npm!
for example: me installing tailwindcss
go to website of tailwindcss
copy the npm code npm install tailwindcss
go to vs code and paste it.
PS C:\Users\laaou\Desktop> npm -version
6.14.14
PS C:\Users\laaou\Desktop> npm install tailwindcss
npm WARN saveError ENOENT: no such file or directory, open 'C:\Users\laaou\package.json'
npm WARN enoent ENOENT: no such file or directory, open 'C:\Users\laaou\package.json'
npm WARN tailwindcss#2.2.7 requires a peer of autoprefixer#^10.0.2 but none is installed. You must install peer dependencies yourself.
npm WARN laaou No description
npm WARN laaou No repository field.
npm WARN laaou No README data
npm WARN laaou No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents#2.3.2 (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents#2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
tailwindcss#2.2.7
updated 1 package and audited 180 packages in 3.857s
17 packages are looking for funding
run npm fund for details
found 0 vulnerabilities
PS C:\Users\laaou\Desktop>
then try use npm fund if you are curious
Happened to me also.
As long as setup processes proceed, I think those specific errors are insignificant. It may take a while to complete, as it uses much Network and CPU. If all setup processes are done and the last message in terminal is the one shared, you probably paused it with your cursor. Just press space or enter and the terminal will release.
the same when this happens, close the window and before restarting or doing anything else, check the node version in the CMD, if the version you selected when downloading appears, everything went well, if nothing appears, then if you should try by other means, sometimes it stays like this because it doesn't give a completed response, that's how the windows power shell is... (it always happens to me).
Related
I am running a Node.js app on Google App Engine, using the following command to deploy my code:
gcloud app deploy --stop-previous-version
My desired behavior is for all instances running previous versions to be terminated, but they always seem to stick around. Is there something I'm missing?
I realize they are not receiving traffic, but I am still paying for them and they cause some background telemetry noise. Is there a better way of running this command?
Example output of the gcloud app instances list:
As you can see I have two different versions running.
We accidentally blew through our free Google App Engine credit in less than 30 days because of an errant flexible instance that wasn't cleared by subsequent deployments. When we pinpointed it as the cause it had scaled up to four simultaneous instances that were basically idling away.
tl;dr: Use the --version flag when deploying to specify a version name. An existing instance with the same version will be
replaced then next time you deploy.
That led me down the rabbit hole that is --stop-previous-version. Here's what I've found out so far:
--stop-previous-version doesn't seem to be supported anymore. It's mentioned under Flags on the gcloud app deploy reference page, but if you look at the top of the page where all the flags are listed, it's nowhere to be found.
I tried deploying with that flag set to see what would happen but it seemingly had no effect. A new version was still created, and I still had to go in and manually delete the old instance.
There's an open Github issue on the gcloud-maven-plugin repo that specifically calls this out as an issue with that plugin but the issue has been seemingly ignored.
At this point our best bet at this point is to add --version=staging or whatever to gcloud deploy app. The reference docs for that flag seem to indicate that that it'll replace an existing instance that shares that "version":
--version=VERSION, -v VERSION
The version of the app that will be created or replaced by this deployment. If you do not specify a version, one will be generated for you.
(emphasis mine)
Additionally, Google's own reference documentation on app.yaml (the link's for the Python docs but it's still relevant) specifically calls out the --version flag as the "preferred" way to specify a version when deploying:
The recommended approach is to remove the version element from your app.yaml file and instead, use a command-line flag to specify your version ID
As far as I can tell, for Standard Environment with automatic scaling at least, it is normal for old versions to remain "serving", though they should hopefully have zero instances (even if your scaling configuration specifies a nonzero minimum). At least that's what I've seen. I think (I hope) that those old "serving" instances won't result in any charges, since billing is per instance.
I know most of the above answers are for Flexible Environment, but I thought I'd include this here for people who are wondering.
(And it would be great if someone from Google could confirm.)
I had same problem as OP. Using the flex environment (some of this also applies to standard environment) with Docker (runtime: custom in app.yaml) I've finally solved this! I tried a lot of things and I'm not sure which one fixed it (or whether it was a combination) so I'll list the things I did here, the most likely solutions being listed first.
SOLUTION 1) Ensure that cloud storage deletes old versions
What does cloud storage have to do with anything? (I hear you ask)
Well there's a little tooltip (Google Cloud Platform Web UI (GCP) > App Engine > Versions > Size) that when you hover over it says:
(Google App Engine) Flexible environment code is stored and billed from Google Cloud Storage ... yada yada yada
So based on this info and this answer I visited GCP > Cloud Storage > Browser and found my storage bucket AND a load of other storage buckets I didn't know existed. It turns out that some of the buckets store cached cloud functions code, some store cached docker images and some store other cached code/stuff (you can tell which is which by browsing the buckets).
So I added a deletion policy to all the buckets (except the cloud functions bucket) as follows:
Go to GCP > Cloud Storage > Browser and click the link (for the relevant bucket) in the Lifecycle Rules column > Click ADD A RULE > THEN:
For SELECT ACTION choose "Delete Object" and click continue
For SELECT OBJECT choose "Number of newer versions" and enter 1 in the input
Click CREATE
This will return you to the table view and you should now see the rule in the lifecycle rules column.
REPEAT this process for all relevant buckets (the relevant buckets were described earlier).
THEN delete the contents of the relevant buckets. WARNING: Some buckets warn you NOT to delete the bucket itself, only the contents!
Now re-deploy and your latest version should now get deployed and hopefully you will never have this problem again!
SOLUTION 2) Use deploy flags
I added these flags
gcloud app deploy --quiet --promote --stop-previous-version
This probably doesn't help since these flags seem to be the default but worth adding just in case.
Note that for the standard environment only (I heard on the grapevine) you can also use the --no-cache flag which might help but with flex, this flag caused the deployment to fail (when I tried).
SOLUTION 3)
This probably does not help at all, but I added:
COPY app.yaml .
to the Dockerfile
TIP 1)
This is probably more of a helpful / useful debug approach than a fix.
Visit GCP > App Engine > Versions
This shows all versions of your app (1 per deployment) and it also shows which version each instance is running (instances are configured in app.yaml).
Make sure all instances are running the latest version. This should happen by default. Probably worth deleting old versions.
You can determine your version from the gcloud app deploy logs (at the start of the logs) but it seems that the versions are listed by order of deployment anyway (most recent at top).
TIP 2)
Visit GCP > App Engine > Instances
SSH into an instance. This is just a matter of clicking a few buttons (see screenshot below). Once you have SSH'd in run:
docker exec -it gaeapp /bin/bash
Which will get you into the docker container running your code. Now you can browse around to make sure it has your latest code.
Well I think my answer is long enough now. If this helps, don't thank me, J-ES-US is the one you should thank ;) I belong to Him ^^
Google may have updated their documentation cited in #IAmKale's answer
Note that if the version is running on an instance of an auto-scaled service, using --stop-previous-version will not work and the previous version will continue to run because auto-scaled service instances are always running.
Seems like that flag only works with manually scaled services.
This is a supplementary and optional answer in addition to my other main answer.
I am now, in addition to my other answer, auto incrementing version manually on deploy using a script.
My script contents are below.
Basically, the script auto increments version every time you deploy. I am using node.js so the script uses npm version to bump the version but this line could easily be tweaked to whatever language you use.
The script requires a clean git working directory for deployment.
The script assumes that when the version is bumped, this will result in file changes (e.g. changes to package.json version) that need pushing.
The script essentially tries to find your SSH key and if it finds it then it starts an SSH agent and uses your SSH key to git commit and git push the file changes. Else it just does a git commit without a push.
It then does a deploy using the --version flag ... --version="${deployVer}"
Thought this might help someone, especially since the top answer talks a lot about using the --version flag on a deploy.
#!/usr/bin/env bash
projectName="vehicle-damage-inspector-app-engine"
# Find SSH key
sshFile1=~/.ssh/id_ed25519
sshFile2=~/Desktop/.ssh/id_ed25519
sshFile3=~/.ssh/id_rsa
sshFile4=~/Desktop/.ssh/id_rsa
if [ -f "${sshFile1}" ]; then
sshFile="${sshFile1}"
elif [ -f "${sshFile2}" ]; then
sshFile="${sshFile2}"
elif [ -f "${sshFile3}" ]; then
sshFile="${sshFile3}"
elif [ -f "${sshFile4}" ]; then
sshFile="${sshFile4}"
fi
# If SSH key found then fire up SSH agent
if [ -n "${sshFile}" ]; then
pub=$(cat "${sshFile}.pub")
for i in ${pub}; do email="${i}"; done
name="Auto Deploy ${projectName}"
git config --global user.email "${email}"
git config --global user.name "${name}"
echo "Git SSH key = ${sshFile}"
echo "Git email = ${email}"
echo "Git name = ${name}"
eval "$(ssh-agent -s)"
ssh-add "${sshFile}" &>/dev/null
sshKeyAdded=true
fi
# Bump version and git commit (and git push if SSH key added) and deploy
if [ -z "$(git status --porcelain)" ]; then
echo "Working directory clean"
echo "Bumping patch version"
ver=$(npm version patch --no-git-tag-version)
git add -A
git commit -m "${projectName} version ${ver}"
if [ -n "${sshKeyAdded}" ]; then
echo ">>>>> Bumped patch version to ${ver} with git commit and git push"
git push
else
echo ">>>>> Bumped patch version to ${ver} with git commit only, please git push manually"
fi
deployVer="${ver//"."/"-"}"
gcloud app deploy --quiet --promote --stop-previous-version --version="${deployVer}"
else
echo "Working directory unclean, please commit changes"
fi
For node.js users if you call the script deploy.sh you should add:
"deploy": "sh deploy.sh"
In your package.json scripts and deploy with npm run deploy
I am having issues with node-red and can no longer run any flows, i am not sure what to do anymore.
i get the following error
Imported unrecognised type: mqtt-env-broker
Flows stopped due to missing node types. Check logs for details.
Tried to remove this module from the palette but get the following error, i am also unable to disable it
Failed to remove: node-red-contrib-mqtt-env
Error: Type in use: mqtt-env-broker
Check the log for more information
I have installed the node-red-admin and tried to remove it from command line, so i issued the following command
sudo node-red-admin remove node-red-contrib-mqtt-env/mqtt-env
i get the following error
404: Cannot DELETE /nodes/node-red-contrib-mqtt-env/mqtt-env
this is what i get when i ran the following command
node-red-admin list
Nodes Types State
node-red-contrib-mqtt-env/mqtt-env mqtt-env in error
mqtt-env out
mqtt-env-broker
node-red-dashboard/ui_audio ui_audio enabled
...
...
node-red/mqtt mqtt in error
mqtt out
mqtt-broker
The flows are stopped because they are trying to use a node type you have not got installed - or in this instance, it appears, is hitting an error when it tries to start
The runtime won't let you remove the node because it is referenced in your flow.
To fix this you need to delete any of the nodes referenced by this module from your flow. The name mqtt-env-broker suggests it is a configuration node rather than a regular flow node. Open the Configuration Nodes sidebar panel (from the drop-down menu) and look for any unknown config nodes. Double click on them and delete them. Once you've removed them, hit deploy and things should start working again.
You should then be able to delete the node module from your runtime.
I've been at it for days but could not solve my problem.
I am running:
mpiexec -hostfile ~/machines -nolocal -pernode mkdir -p $dstpath where $dstpath points to current directory and "machines" is a file containing:
node01
node02
node03
node04
This is the error output:
Failed to parse XML input with the minimalistic parser. If it was not
generated by hwloc, try enabling full XML support with libxml2.
[node01:06177] [[6421,0],0] ORTE_ERROR_LOG: Error in file base/plm_base_launch_support.c at line 891
--------------------------------------------------------------------------
ORTE was unable to reliably start one or more daemons.
This usually is caused by:
* not finding the required libraries and/or binaries on
one or more nodes. Please check your PATH and LD_LIBRARY_PATH
settings, or configure OMPI with --enable-orterun-prefix-by-default
* lack of authority to execute on one or more specified nodes.
Please verify your allocation and authorities.
* the inability to write startup files into /tmp (--tmpdir/orte_tmpdir_base).
Please check with your sys admin to determine the correct location to use.
* compilation of the orted with dynamic libraries when static are required
(e.g., on Cray). Please check your configure cmd line and consider using
one of the contrib/platform definitions for your system type.
* an inability to create a connection back to mpirun due to a
lack of common network interfaces and/or no route found between
them. Please check network connectivity (including firewalls
and network routing requirements).
--------------------------------------------------------------------------
[node01:06177] 1 more process has sent help message help-errmgr-base.txt / failed-daemon-launch
[node01:06177] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
Failed to parse XML input with the minimalistic parser. If it was not
generated by hwloc, try enabling full XML support with libxml2.
[node01:06181] [[6417,0],0] ORTE_ERROR_LOG: Error in file base/plm_base_launch_support.c at line 891
I have 4 machines, node01 to node04. In order to log into these 4 nodes, I have to first log in to node00. I am trying to run some distributed graph functions. The graph software is installed in node01 and is supposed to be synchronised to the other nodes using mpiexec.
What I've done:
Made sure all passwordless login are setup, every machine can ssh to any other machine with no issues.
Have a hostfile in the home directory.
echo $PATH gives /home/myhome/bin:/home/myhome/.local/bin:/usr/include/openmpi:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
echo $LD_LIBRARY_PATH gives
/usr/lib/openmpi/lib
This has previously worked before, but it just suddenly started giving these errors. I got my administrator to install fresh machines but it still gave such errors. I've tried doing it one node at a time but it gave the same errors. I'm not entirely familiar with command line at all so please give me some suggestions. I've tried reinstalling OpenMPI from source and from sudo apt-get install openmpi-bin. I'm on Ubuntu 16.04 LTS.
You should focus on fixing:
Failed to parse XML input with the minimalistic parser. If it was not
generated by hwloc, try enabling full XML support with libxml2.
[node01:06177] [[6421,0],0] ORTE_ERROR_LOG: Error in file base/plm_base_launch_support.c at line 891
I had a question I was hoping someone might have an answer to. Essentially what I'm doing is try to ensure I'm always using a fixed, slightly older version of phpunit, which I've placed in my module's file resources.
The manifest:
file
{
"/usr/bin/phpunit":
ensure => file,
owner => 'root',
group => 'root',
mode => 0755,
source => "puppet:///modules/php/phpunit"
}
Preparation: I download the current ('wrong') version of phpunit and place it in /usr/bin.
So the first run puppet succeeds:
Notice: Compiled catalog for <hostname> in environment production in 3.06 seconds
Notice: /Stage[main]/Php/File[/usr/bin/phpunit]/content: content changed '{md5}9f61f732829f4f9e3d31e56613f1a93a' to '{md}38789acbf53196e20e9b89e065cbed94'
Notice: /Stage[main]/Httpd/Service[httpd]: Triggered 'refresh' from 1 events
Notice: Finished catalog run in 15.86 seconds
Then I download the current (still 'wrong') version of phpunit and place it in /usr/bin again.
This time the puppet run fails.
Notice: Compiled catalog for <hostname> in environment production in 2.96 seconds
Error: Could not back up /usr/bin/phpunit: Got passed new contents for sum {md5}9f61f732829f4f9e3d31e56613f1a93a
Error: Could not back up /usr/bin/phpunit: Got passed new contents for sum {md5}9f61f732829f4f9e3d31e56613f1a93a
Error: /Stage[main]/Php/File[/usr/bin/phpunit]/content: change from {md5}9f61f732829f4f9e3d31e56613f1a93a to {md5}38789acbf53196e20e9b89e065cbed94 failed: Could not back up /usr/bin/phpunit: Got passed new contents for sum {md5}9f61f732829f4f9e3d31e56613f1a93a
What gives? If I delete the file ( /var/lib/puppet/clientbucket/9/f/6/1/f/7/3/2/9f61f732829f4f9e3d31e56613f1a93a/ ) from my filebucket it will work again... for the next run, but not the one after that.
What am I doing wrong?
I'd appreciate any input and thanks in advance.
Been having this error as well. I solved it with a combination of two previous answers.
Firstly I had to delete /var/lib/puppet/clientbucket on the client node by running:
sudo rm -r /var/lib/puppet/clientbucket
Just doing this will only let it run once more.
Then I had to mark the backup => false to stop it recreating the file, missing out either step failed to solve it for me. The accepted answer is incorrect by saying there is
"no solution other than upgrading".
I was able to fix the same problem by removing /var/lib/puppet/clientbucket on the client node.
This node has been running out of disk space, so puppet has probably incorrectly stored empty files there.
As a workaround, you can set backup => false in the file resource. This is a little unsafe, of course.
This has no solution other than to upgrade since there's a bug in certain versions of puppet where files containing both UTF8 and binary characters are treated wrongly, and it results in an error message.
https://tickets.puppetlabs.com/browse/PUP-1038
The ridiculously overcomplicated solution I used as a workaround is to have a .tar file in the file resource which notifies an exec which untars and places the actual executable in the correct directory, making sure the timestamp for the latter is newer than the former.
It's far from ideal but it works in cases like mine where upgrading puppet to the most current version isn't an attractive option.
So, I'm having this odd issue with my CruiseControl.net project. I have a ccnet.config file that goes and pulls from my bitbucket repo, runs a basic build, then runs some unit tests, and then finally copies the tested files out to the webroot. Seems pretty basic, even for being my first time using CC.Net.
I, of course, would like this to run when I do commits. Failing writing some sort of web page that bitbucket can invoke through it's services framework, I settled for having CC run a scheduled build, and only run the full build if there's source control changes.
After some googling, I found out that in 1.6, it has a cronTrigger. Excactly what I need. So, I add the following chunk to my config:
<cronTrigger>
<cronExpression>*/5 * * * *</cronExpression>
</cronTrigger>
Then it triggers fine, but then I get a loop of this in the console:
[HMS:INFO] Calling hg log -r tip --template {rev} --noninteractive
[HMS:DEBUG] Starting process [C:\Program Files (x86)\TortoiseHg\hg.exe] in working directory [C:\build\hms\src] with arguments [log -r tip --template {rev} --noninteractive]
[HMS:DEBUG] Not setting PriorityClass on [C:\Program Files (x86)\TortoiseHg\hg.exe] to default Normal
[8:DEBUG] [HMS C:\Program Files (x86)\TortoiseHg\hg.exe] standard-error stream closed -- null received in event
[7:DEBUG] [HMS C:\Program Files (x86)\TortoiseHg\hg.exe] 60
[7:DEBUG] [HMS C:\Program Files (x86)\TortoiseHg\hg.exe] standard-output streamclosed -- null received in event
[3:DEBUG] [HMS C:\Program Files (x86)\TortoiseHg\hg.exe] process exited event received
[HMS:INFO] No modifications detected.
This loop continues until I go in and remove the cronTrigger block. I don't really want this thing busy-waiting on my server for a change, and I'm sure BitBucket doesn't smile upon several requests per second.
So, in short, how do I stop this thing from molesting bitbucket? Stop using CC.Net? Resign myself to hitting the "Build" button?
Also: my ccnet.config file for reference: http://pastebin.com/6jSPxVTk
I said screw it, I moved to Hudson instead. A bit heavier on my server, but it supports a URL to post to, so I can drop that into BitBucket's "Services" option, so no polling.
I also get a free Jabber bot, and Chuck Norris.