I'm running into a strange problem whenever I start a particular build, and I can't get my head around it.
I just imported an existing VSTS-repository into my new GIT-Repository on Azure DevOps. My next step is to create a Build-pipeline which should lead to an artifact which I can deploy. For the company I work for I've done this many times, but I've never seen this error before.
The buildpipeline is setup, and as soon as I start a build it immediately fails with the following error;
Hopefully somebody can help out in resolving this.
UPDATE - Added settings for retrieving sources
After posting the second screenshot and going through everything again properly, I saw that I didn't point the Build Pipeline to the proper GIT-Repository in Azure Devops. After updating this, the issue was resolved.
Related
I'm really new to using git so this might be a dumb issue, but somehow my colleague also doesn't know how to fix it.
So i pushed my code which worked without a problem.
When trying to commit i kept having an issue where it came out that the node.js version was too old.
My colleague fixed the issue and updated the node.js version.
However when i try to "Rerun failed jobs" it is still giving me the same issue as before.
I tried to push the code again and commit again but it obviously tells me that everything is already up-to-date.
When trying to pull the code again i just get the code that i already pushed.
My next try would be to push the wrong code again just to immediately push the right one afterwards, but i feel like there has to be a better way. Has anyone experienced this before and knows a fix for this problem?
The described behavior is how Azure DevOps works.
In order to get a run with your new code you should create a new run using the -> Run Pipeline button. This will checkout your new code. When using rerun failed job, the Azure DevOps will keep the same code, settings and will try to rerun the same job. That's why your pipeline fails.
The same apply with the releases. Every time you need to get a new Release (after you updated your pipeline) you should use the Create Release button and not run the previous failed one.
To conclude you should first commit your changes with the updated node version and then run a new pipeline.
I set up a workspace and I am following the Enforce Policy with Sentinel hands on guide.
I see the following message in the run tab:
As soon as I try to press the queue plan button I receive this error:
My configured variables are:
Is there something else I need to configure to be able to queue a plan?
Executing from the cli I was able to trigger a run (in TF Cloud) that only included the plan step. The run execution can be viewed if I access the specific run url directly.
Any help, suggestions are more than welcome!
I guess you've already resolved this issue, but I post my resolution anyway.
When this issue occurred, I had wrong workspace's name settings.
There were two workspaces with similar names, and I don't know why this happened. Then I deleted one of them.
On the other one occurred this issue.
In the end, when I deleted the workspace and recreated it, I didn't have the issue occurring anymore.
In my case I didn't have duplicate / similar names workspaces (only one workspace). I found that after running terraform apply locally once first, the UI controls started to work as expected.
I want to run our automated ui tests from xamarin ui-tests in appcenter.
But i don't want to start the test runs manually, but rather being triggerd by my Azure DevOps build pipelin. I already found the task for this, but unfortunately the documentation only contains a sample for espresso, and none for xamarin ui-test.
So right now i'm a bit lost on what i have to setup and what commands are really needed to get this going.
I already did successfully run the ui-tests manually on app-center, but getting this married to azure devops is a bit too much for my brain right now (maybe i just overlooked some basic things)
[edit1] I forgot to mention, that i (for some not know reason) cannot use the old graphical yaml builder of azure devops, but are stuck to the yaml file editor. So since the documentation for the graphical yaml builder is much better, i would also be glad if someone would show me, how i could switch back to it in azure devops.
[/edit1]
[edit2]
I think I should just open my eyes before asking a question for which the answer is directly in front of me.
so, i found the graphical yaml builder just on the right of the window :/.
I'll leave this question though and updated it with a working sample file, once i finished creating one.
If someone out there is faster than me, i'm happy to upvote and accept his answer though :).
[/edit2]
So, if anyone of you has a build pipeline task for automated xamarin ui-tests to help me out, i would be really greatful.
Best regards and thx in advance.
Maverick
Update
I now get the following error message:
##[error]Error: Cannot find any file based on d:\a\1\s\com.docuware.mobileclient.apk.
In my Publish Task the file is taken from here:
Upload 'd:\a\1\b\Debug' to file container: '#/9635693/drop'
This is the path i gave for the apk file:
appFile: '$(System.DefaultWorkingDirectory)/com.companyname.filename.apk'
of course i see, that the file is in subfolder named "Debug", but how to tell the task to look in d:\a\1\b for debug and not in d:\a\1\s?
I am currently getting the following error on VSTS when trying to do publish a release to a Azure:
The release definition cannot be saved because the environment 'App-Service-Template' references a service endpoint that is in dirty state. Update the endpoint(s) and retry the operation. Details: 'System.Collections.Generic.List`1[System.String]'
I have tried the following troubleshooting steps and still get the same error:
I have recreated the service end point in VSTS and it fails
I have recreated the Resource group in Azure that the service point connects to and have tried to connect the end point to a empty resource group and it fails
I followed the manual steps of creating the end point connection, i then can verify the status of the connection which passes. I then try to publish the release to Azure and get the above error message.
Lastly i have tried all the MS VSTS recommended troubleshooting with still no luck https://learn.microsoft.com/en-us/vsts/pipelines/release/azure-rm-endpoint?view=vsts
I am all out of ideas. Any Help would be appreciated.
Cheers
What ultimately fixed this issue for us was abandoning and deleting the failed releases, and then a new build and release triggered from that new build.
(one weird quirk we encountered was that the release sat in the last stage for over 8 minutes: 'wait for console output from agent'... when I left the release and came back it said successful with the last stage only taking 27 seconds)
We had the exact same error. I also ran through the points on your list with no luck, before arriving at the solution with a new build and release.
I have managed to resolve the issue. It was caused by a corrupt resource group in Azure. Deleted the resource group and created it with a different name and this worked. No idea why this happened as there were no logs and resources where running in the group, just couldn't deploy new or change existing ones.
I have an Azure Web application that I checked into TFS yesterday with no issues. Upon checking in, the resource manager will inject our nuget packages and deploy if it builds successfully.
I made a few changes (added a class) and checked in today. I received this error on the build:
Here's the quote to help the future search bots:
Exit code 1 returned from process: file name 'tf', arguments 'vc unshelve Gated_xxxxxx;****** /loginType:OAuth /login:.,******** /noprompt'.
I looked into the log response, to see if I get more detail, but it says the exact same thing. I have not changed my password or username.
How can I debug this to figure out the issue?
UPDATE
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
You can receive that error as well if you try to check in a file that is in a project that is not mapped in your build definition.
Let's say that you have a file named FileA.cs that is in a project named ProjectA.csproj. If you do changes in FileA.cs and this file is included in your changes, you need to map ProjectA.csproj in the Get source step of the build definition.