I am working on a project to develop an Azure DevOps release task extension. Recently, I am getting this warning message printed multiple times in the logs when the release task runs- "Warning: Use Cipheriv for counter mode of aes-256-ctr".
I was not getting it earlier. And the time when I started getting this error, I only changed some console.log(..), and not even any code that could possibly trigger this error. (Might be some npm dependency updates!)
Any idea regarding why am I getting this error, and how to fix it! If not, how to disable it?
P.S. - I know this question has been asked and could probably be categorized as duplicate. But I am asking in the context of Azure DevOps release tasks, others are independent node.js projects. And, those fixes didn't work for me.
This is related to the Azure-Pipelines-Task-Lib and the Azure-Pipelines-agent and outside of your control. The problem should be fixed in those projects or their dependencies.
Since these all ship with the agent installer and the tasks themselves, this is not directly under your control.
This is likely caused by the dependency of the Agent on Node 6. There is work in progress to support Node 10 LTS on the agent (Node 10 now ships side-by-side in the agent installer).
The Azure-Pipelines-Agent calls the wrong method here.
let encryptKey = crypto.randomBytes(256);
let cipher = crypto.createCipher("aes-256-ctr", encryptKey);
let encryptedContent = cipher.update(secret, "utf8", "hex");
encryptedContent += cipher.final("hex");
As far as I can tell it should call crypto.createCipheriv() instead of crypto.createCipher() when running on Node 8 or higher. The Azure-Pipelines-Task-Lib seems to rely on the same piece of code.
It looks like 2.8.0 of the Azure-Pipelines-Task-Lib fixes this. It's on npm now, so upgrade to make these warnings disappear.
Related
While using cargo install spl-stake-pool-cli
I am getting issues with the last step. Please check the attached screenshot.
so for now you'll need to be using strictly version 1.6.11 of the SDK and it should work. These dependency changes will also be added to the next release so you can expect it moving forward.
this is my first question ever. I'm trying to run an Adonis.js app by entering adonis serve --dev at the terminal. The messages are always the same in this succession:
SERVER STARTED
Watching files for changes...
Fatal error in , line 0
Check failed: U_SUCCESS(status).
FailureMessage Object: 000000D7655ECBA0Application crashed, make sure to kill all related running process, fix the issue and re-run the app
The only thing that changes is the FailureMessageObject. My Node version is 12.0, npm 6.9.
I can't say anything seriously working on your situation cause you gave me no detailed data but I know that surely you are doing something wrong.
It could be better if you at least mentioned the version of adonisjs you've been using.
Anyway, if you learned to run your server from a video from someone else's youtube channel, I strongly recommend you to read documentation and stop watching those videos.
And for adonisjs there are 2 different documentation:
adonisjs's Documentation, version 4.1 or less.
You can change the version on top left combo box.
adonisjs's preview Documentation, version 5.0.
Actually the documentation is not still completed at this time but the version is stable. yeah, that's the reason why I wrote preview.
And that's it, start recreating an adonisjs app from documentation guides.
I solved it. It was something with node or npm. I followed this steps enumerated in this post: How to completely remove node.js from Windows. Reinstalled node. Installed Adonis and it's CLI again and created an app and this time the app didn't crashed, and ran smoothly (after that I also created some migrations and they too worked well).
I have a project that was using the VS 2017 agent pool in Azure devops and building without issues. In order to use features from newer versions of C#, this has been updated to the windows-2019 Agent specification. Suddenly, the build step fails with errors following the Running Code Analysis line. Looking at the errors in the default ruleset in Visual Studio, they are all marked as warnings rather than errors so shouldn't be causing the build to fail
There are too many issues to fix right now, as this is an older project. Apart from creating a custom ruleset that disables all of these rules, is there a way to keep the new features of Windows-2019 without having code analysis fail the build?
In answer to the comment question, this is not a yaml pipeline, but done in the legacy UI
This is known issue with Visual Studio 16.8. Here is the ticket with the same issue on github.
You can try workarounds provided by this link:
Please set ‘CodeAnalysisTreatWarningsAsErrors’ property to false if
you prefer CA warnings not to be treated as errors:
https://learn.microsoft.com/dotnet/fundamentals/code-analysis/overview#treat-warnings-as-errors
If you are running legacy binary FxCop: ‘RunCodeAnalysis’ property
is used for executing deprecated binary FxCop based CodeAnalysis.
Please refer to
https://learn.microsoft.com/visualstudio/code-quality/fxcop-analyzers-faq?view=vs-2019#does-the-runcodeanalysis-msbuild-project-property-run-analyzers.
The default value for the property is false, so you should consider
just removing this property from your project file OR setting it
explicitly to false. Please consider migrating from legacy
CodeAnalysis to source based CodeAnalysis:
https://learn.microsoft.com/visualstudio/code-quality/migrate-from-legacy-analysis-to-fxcop-analyzers?view=vs-2019
We have a function deployed to azure running the v2 runtime. If I go to the function in the portal to try to upgrade it to v3, I see this message "Cannot upgrade with existing functions: Major version upgrades can introduce breaking changes to languages and bindings. When upgrading major versions of the runtime, consider creating a new function app and migrate your functions to this new app."
However, I was able to change the function in Visual Studio and deploy, using a simple test deploy of right-click publish, and the publishing process upgraded the deployed function to runtime v3.
Are there any gotchas we may run into using this approach? Is it better practice to create new azure function resources to deploy to a clean v3 azure function?
Thanks
Apparently no one else has this question or the answer is obvious. In any case, here's Microsoft's recommendation from their support personnel (grammar/language translation is Microsoft's):
Based on the official documentation changing the version can be made by changing the App Setting "FUNCTIONS_EXTENSION_VERSION" value form ~2 to ~3 however this can cause some problems if there are any dependencies unique to version 2 of the runtime, you can read more about this in the following link
https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions#migrating-from-2x-to-3x
Now based on my experience the safest an easiest way to archive [achieve] this is to deploy the code into a Function app that was created targeting the version 3 of the runtime this is to assure [ensure] that it will only have the dependencies form [from] version 3 and not having anything extra from 2 left after changing the version directly from the portal
The idea with this is to avoid having conflicts from between assets form version 2 or missing assets from version 3
Suppose you are using c# function, if yes, the major update about v2 to v3 is the .net core version. So mostly if your code could work with the update that means your dependencies are compatible with .net core3, so mostly it won't crash.
And there is an official doc about migrating from 2.x to 3.x.
And about deploying, if the runtime is different when you deploy it will prompt to update the portal runtime, so it won't affect the function running.
What is the best practice for using runtime version given that the runtime introduced breaking changes, and using specific version will cause issue given that runtime will be removed regularly.
https://github.com/Azure/app-service-announcements-discussions/issues/90
Please let me explain below:
Scenario 1:
When below is used,
FUNCTIONS_EXTENSION_VERSION =~2
Our code broke with the latest runtime. Because ~2 means it uses the latest version.
https://github.com/Azure/azure-functions-host/issues/4203
Scenario 2:
However, when below is used,
FUNCTIONS_EXTENSION_VERSION = specific version
Our code brok again with the latest runtime. Because the specified runtime is removed by Azure Functions, and the latest runtime with breaking changes is used instead,
https://github.com/Azure/app-service-announcements-discussions/issues/90
Again, what is the better way to reduce the error?
Updates
In terms of time frame, how a latest runtime works when it is publicly downloadable and it is rolled out on Azure Functions? For example, how advance is the runtime available before it is rolled out to Azure fucntions?
How long will an old runtime be kept for on Azure Functions after latest runtime rollout? Based on what factors are an old runtime decided to be deteled?
The best and recommended practice is to use the latest. It is a rare occurrence, but unfortunately, a regression was introduced with a new release impacting your app.
If you want to perform validation on new versions, the recommendation is to:
Subscribe to new release notifications at
https://github.com/Azure/app-service-announcements/issues
Pin yourself to the current release you've validated against
As a new version is introduced, update a test environment to adopt that new version (or have a test environment that auto updates, using ~2). If you have a test environment set with auto-updates and automated tests, this makes the process significantly simpler.
Once validated, update the production environment to that new version
If you find an issue, reporting allows us to ensure we don't remove
the version that works.
We always maintain the newly deployed version and the previous release, and, aside from hotfixes and small ad-hoc deployments, the release cadence is ~2 weeks. Anything that has been flagged as a version that needs to be kept due to issues intruduced by a release (forcing customers to pin) is also kept.