I didn't found any similarly question. I have Azure DevOps 2020 on Premise and when I want to rebuild codeindex then I get message TF400860: The current version of the following service is not supported: CodeSense. Version: 3, MinVersion: 3.
I try followed command: tfsconfig codeIndex /reindexall /collectionName:MyCollection
But same error I get by this command: tfsconfig codeIndex /indexingStatus /collectionName:MyCollection
What could be wrong?
Thanks
Related
So I cloned their repository, but how do I actually build the tasks?
Here is my scenario. We use Azure DevOps Server 2020 (on prem). All of our build pipelines run the Index Sources & Publish Symbols task
However, it has a bug https://github.com/microsoft/azure-pipelines-tasks/issues/14852. Luckily a fix was merged to master. However, we are not going to see it until it is propagated to the Azure DevOps Server edition and only All Mighty knows when it would happen.
So, I would like to build that task locally and upload to our Azure DevOps server. But I cannot find instructions on how to do it.
So, how can I build and consume it in our Azure DevOps Server?
EDIT 1
Tried to follow the procedure in https://github.com/microsoft/azure-pipelines-tasks/blob/master/ci/build-all-steps.yml, but it did not work.
The first step that seems relevant to me is https://github.com/microsoft/azure-pipelines-tasks/blob/6ab084f52e582370880127132d1c449634c9bfbc/ci/build-all-steps.yml#L39:
- script: |
cd ci
cd verifyMinAgentDemands
npm install
node index.js
displayName: Verify all min agent demands are valid
And it is fine:
C:\work\azure-pipelines-tasks\ci\verifyMinAgentDemands [master ≡]> npm install
npm WARN verifyminagentdemands#1.0.0 No description
npm WARN verifyminagentdemands#1.0.0 No repository field.
added 52 packages from 78 contributors and audited 52 packages in 1.743s
found 2 low severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
C:\work\azure-pipelines-tasks\ci\verifyMinAgentDemands [master ≡]> node .\index.js
##vso[task.debug]agent.TempDirectory=undefined
##vso[task.debug]agent.workFolder=undefined
##vso[task.debug]loading inputs and endpoints
##vso[task.debug]loaded 0
##vso[task.debug]Agent.ProxyUrl=undefined
##vso[task.debug]Agent.CAInfo=undefined
##vso[task.debug]Agent.ClientCert=undefined
##vso[task.debug]Agent.SkipCertValidation=undefined
Verifying min agent demands.
Latest version of the Agent that's fully rolled out is 2.195.0.
The next step (https://github.com/microsoft/azure-pipelines-tasks/blob/6ab084f52e582370880127132d1c449634c9bfbc/ci/build-all-steps.yml#L47) seems to be relevant too:
- script: node make.js build --task "$(task_pattern)"
displayName: Build
condition: ne(variables['numTasks'], 0)
But:
C:\work\azure-pipelines-tasks [master ≡]> node make.js build --task PublishSymbolsV2
> prepending PATH C:\work\azure-pipelines-tasks\node_modules\.bin
tsc tool:
Version 2.3.4
C:\work\azure-pipelines-tasks\node_modules\.bin\tsc
npm tool:
6.14.12
C:\Program Files\nodejs\npm
------------------------------------------------------------
Building: PublishSymbolsV2
------------------------------------------------------------
> getting task externals
Downloading file: https://vstsagenttools.blob.core.windows.net/tools/symstore/2/symbol.zip
Could not use "nc", falling back to slower node.js method for sync requests.
C:\work\azure-pipelines-tasks\node_modules\sync-request\index.js:77
throw new Error(res.stderr.toString());
^
Error
at doRequestWith (C:\work\azure-pipelines-tasks\node_modules\sync-request\index.js:77:11)
at doRequest (C:\work\azure-pipelines-tasks\node_modules\sync-request\index.js:20:10)
at downloadFile (C:\work\azure-pipelines-tasks\make-util.js:411:22)
at downloadArchive (C:\work\azure-pipelines-tasks\make-util.js:451:27)
at C:\work\azure-pipelines-tasks\make-util.js:644:33
at Array.forEach (<anonymous>)
at getExternals (C:\work\azure-pipelines-tasks\make-util.js:639:25)
at C:\work\azure-pipelines-tasks\make.js:193:13
at Array.forEach (<anonymous>)
at Function.target.build (C:\work\azure-pipelines-tasks\make.js:158:14)
C:\work\azure-pipelines-tasks [master ≡]>
What is now?
How are you?
I'm facing to a very odd error after upgrading my Serverless version from 2.35 to any newer version.
Using the exactly the same .yml that deploys in 2.35, in newer versions the following error is thrown:
ProviderARNs need to be valid Cognito Userpools:
Serverless Error ----------------------------------------
An error occurred: ApiGatewayCognitoAuthorizer - ProviderARNs need to be valid Cognito Userpools. Invalid ARNs-
arn:aws:cognito-idp:${file(./src/config/dev.json):REGION}:${file(./src/config/dev.json):AWS_ACCOUNT}:userpool/${file(./src/config/dev.json):COGNITO_POOL_ID} (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: e8403d66-ec5c-4ead-9528-308baed7640f; Proxy: null).
Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Issues: forum.serverless.com
Your Environment Information ---------------------------
Operating System: darwin
Node Version: 12.22.1
Framework Version: 2.50.0 (local)
Plugin Version: 5.4.4
SDK Version: 4.3.0
Components Version: 3.17.0
In the deep, the problem is that the CloudFormation template generated in the deployment is unable to resolve variables that 2.35 and previous versions resolved properly (specially those variables that depends on the config file), for example in my code:
ApiGatewayCognitoAuthorizer:
DependsOn:
- ApiGatewayRestApi
Type: AWS::ApiGateway::Authorizer
Properties:
Name: cognito-authorizer
IdentitySource: method.request.header.Authorization
ProviderARNs:
- "arn:aws:cognito-idp:${${self:custom.config}:REGION}:${${self:custom.config}:AWS_ACCOUNT}:userpool/${${self:custom.config}:COGNITO_POOL_ID}"
RestApiId:
Ref: ApiGatewayRestApi
Type: COGNITO_USER_POOLS
Same variable replacements are used in other resources, lambdas, etc. but the error is only thrown to API Cognito Authorizer, I don't understand...
Thank you all for your attention and help :)
Solved using https://www.serverless.com/framework/docs/environment-variables/, ie, loading environment variables from .env files instead custom .json files.
Thanks anyway to everybody.
I'm trying to deploy a Java 11 Maven project in App Engine(Standard), using mvn appengine:deploy command.
It was successful until last week.
This week after Google cloud sdk got updated to 288.0.0 the deployment is failing with below error.
i tried reverting Cloud SDK version but still the issue persists.
Project Id is of format- google.com:abc-xyz
Cloud Build Log Snippet below:
....
Finished Step #2 - "detector"
Starting Step #3 - "analyzer"
Step #3 - "analyzer": Already have image (with digest): us.gcr.io/gae-runtimes/buildpacks/java11/builder:java11_20200223_11_0_RC00
Step #3 - "analyzer": ERROR: failed to access previous image: could not parse reference: us.gcr.io/**google.com:abc-xyz**/app-engine-tmp/ttl-7d/default/buildpack-app:latest
Finished Step #3 - "analyzer"
ERROR
ERROR: build step 3 "us.gcr.io/gae-runtimes/buildpacks/java11/builder:java11_20200223_11_0_RC00" failed: step exited with non-zero status: 1
-Thanks
Your error appears to be a result of the project ID google.com:${ID}
The causes an error for Container Registry because it wants e.g.
[us.]gcr.io/${PROJECT}/${IMAGE}...
but it's getting
[us.]gcr.io/google.com:${PROJECT}..
IIRC google.com: is a defunct method of specifying projects. You should just use ${PROJECT} without any domain prefixing.
Hmmm... you said that the project is in production and this used to work. I think this is possibly (effectively) a breaking change for you. I'll Google it but, using domain prefixes (google.com:) used to be a thing in GCP and perhaps this is now formally deprecated. Guess (!?).
We have recently migrated from TFS 2010 to TFS 2015 (Update 2) and everything seems to work fine apart from
the following error we get every 12 minutes.
TF53010: The following error has occurred in a Team Foundation component or extension:
Application Domain: TfsJobAgent.exe
Assembly: Microsoft.TeamFoundation.Framework.Server, Version=14.0.0.0, Culture=neutral,
Detailed Message: TF221123: Job Version Control Warehouse Sync for team project collection JLT TFS 2010 was unable to run after 20 attempts.
After checking "Process status" through the "Warehouse Control Web Service" I get the following message.
I would like to understand the core reason of why this is happening and how we can resolve this isue?
<Job JobProcessingStatus="DataChange" Name="Version Control Warehouse Sync">
<LastRun Result="Stopped" EndTimeUtc="2016-06-30T14:10:50.19Z" ExecutionStartTimeUtc="2016-06-30T14:00:49.877Z" QueueTimeUtc="2016-06-30T14:00:49.203Z">
<ResultMessage>
[Version Control Warehouse Sync]: ---> MakeDataChanges() result=DataChangesPending.
---> MakeDataChanges() result=DataChangesPending.
---> MakeDataChanges() result=DataChangesPending.
---> MakeDataChanges() result=DataChangesPending. --->
...
...
---> TF221123: Job Version Control Warehouse Sync for team project collection JLT TFS 2010 was unable to run after 20 attempts.
</ResultMessage>
</LastRun>
<CurrentRun ExecutionStartTimeUtc="2016-06-30T14:12:50.75Z" QueueTimeUtc="2016-06-30T14:12:50.19Z" JobState="Running"/>
</Job>
After checking this further we found that this is a known issues (confirmed by Microsoft) and has been fixed in TFS 2015 (Update 3).
Although, it requires to apply the latest Update of TFS 2015, however, it can be achieved by applying the following workaround at database level.
Please run the following script on the TFS Collection Database
DECLARE #partitionId INT = 1
DECLARE #registryUpdates typ_KeyValuePairStringTableNullable
INSERT #registryUpdates ([Key], Value)
SELECT ‘#\Configuration\VersionControl\CodeChurn\InUpgrade\’, NULL
EXEC prc_UpdateRegistry #partitionId, #registryUpdates
DROP TABLE tbl_UpgradeCodeChurn
Detailed information can be found in the following article.
After running this script and leaving it for few hours resolved this reported issue.
When I originally set up my Rules Engine service in Bluemix, I could deploy from my Eclipse Juno environment just fine. I just tried to deploy a new project this morning, and I got the following error in the deployment report in Eclipse:
ilog.rules.res.model.IlrAlreadyExistException: Unknown RuleApp: /RefillRulesApp/1.0. at
com.ibm.rules.res.internal.MutableRepositoryRESTAdapter.addRuleApp(MutableRepositoryRESTAdapter.java:86)
at
com.ibm.rules.decisionservice.internal.RESClient$3.execute(RESClient.java:332)
at
com.ibm.rules.decisionservice.internal.RESClient$3.execute(RESClient.java:1)
at
com.ibm.rules.decisionservice.internal.RESClient.safeInvokeRES(RESClient.java:132)
at
com.ibm.rules.decisionservice.internal.RESClient.deploy(RESClient.java:299)
at
com.ibm.rules.decisionservice.internal.DsResRestClient.deploy(DsResRestClient.java:168)
at
com.ibm.rules.studio.model.decisionservice.impl.Server.deploy(Server.java:310)
at
com.ibm.rules.decisionservice.DsRuleAppDeployManager.deploy(DsRuleAppDeployManager.java:38)
at
com.ibm.rules.decisionservice.DsDeployManager.deploy(DsDeployManager.java:88)
at
com.ibm.rules.studio.decisionservice.SDsXOMDeploymentJob.deploy(SDsXOMDeploymentJob.java:203)
at
com.ibm.rules.studio.decisionservice.SDsRuleAppDeploymentJob.deployRuleApp(SDsRuleAppDeploymentJob.java:101)
at
com.ibm.rules.studio.decisionservice.SDsRuleAppDeploymentJob.deploy(SDsRuleAppDeploymentJob.java:65)
at
com.ibm.rules.studio.decisionservice.SDsXOMDeploymentJob.runInWorkspace(SDsXOMDeploymentJob.java:81)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)**
I checked the RES console server log and there isn't any untoward messages in it
The Decision Server version infomation looks like this:
Version: Decision Server 8.7.0.1 , Decision Engine 1.10.0 Patch level: Build #2 on 2015-03-13 16:54:27 Release status: COMMERCIAL
Persistence Type: datasource (DB2/LINUXX8664 SQL10070) Startup
Time: Jan 29, 2016 4:17:18 PM GMT-05:00 Last Update Time: Feb 2, 2016
3:01:23 PM GMT-05:00
I checked for updates to the Eclipse plugin, and it looks like I am up to date.
If I check in the Explorer in the RES console, I can see that it partially deployed:
Deploy Picture
Notice how the rule app is greyed-out.
Any ideas? Thanks...
I found that if I deploy the RuleApp from a 'Rule project for Decision Service', I get the same error. Can you deploy it from a RuleApp project which references a 'Standard Rule Project'? That should fix the issue.