Please, observe:
[Error]Failed to create ref refs/tags/dryrun-master-CI_64.0.0.25914-noat-test at 330dd52a89ed97f5dcd216bcf89e04b864247053.
[Error]Failed to create ref refs/tags/dryrun-master-CI_64.0.0.25914-noat-test at 330dd52a89ed97f5dcd216bcf89e04b864247053.
Created ref refs/tags/dryrun-master-CI_64.0.0.25914-noat-test at 330dd52a89ed97f5dcd216bcf89e04b864247053.
Running the build with the diagnostics does not actually produce any more output in this step.
The build url is https://dev.azure.com/Ceridian-dryrun/SharpTop/_build/results?buildId=1672629&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774&t=9ff468ea-e6fc-49e0-b3ce-f8332e9d6e3d, but I doubt it can be viewed by anyone.
I tried to reproduce it on a small repo, but apparently only this particular build is vulnerable.
How is one supposed to troubleshoot it? I am more than willing to inspect the source code of that task, but it is not amongst the tasks found in https://github.com/microsoft/azure-pipelines-tasks/tree/master/Tasks. So, what can we do here?
Another weird thing - the duration of the step. It took 5 minutes to fail.
Related
I'm performing an api call in my jenkinsfile that requires specifying a path to file 'A'. Assuming file A is located on the same repo, I am not sure how to refer to file A when running the jenkinsfile.
I feel like this has been done before, but I can't find any resource. Any help is appreciated.
You don't say whether you are using a scripted or declaritive Jenkinsfile, as the details differ. However the principle is the same as far as I am concerned. Basically to do anything with a file you will need to be within a node clause - essentially the controller opens a session on one of the agents and does actions there. You need to checkout your repo on that node:
The scripted Jenkinsfile would look something like (assuming you are not bothered about which node you are running on):
node("") {
checkout scm // "scm" equates to the configuration that the job was run with
// the whole repo will be now available
}
Our structure for a release in azure devops is to
deploy our app to our DEV environment.
Kick off my Selenium (Visual Studio) tests against that environment.
If passes, moves to our TEST environment.
If fails/hard stop.
We want to add new piece/functionality, starts same as above, Except instead of hard stop. 5) if default step fails, continue to next step. 6) New detail testing starts (turns on screen recorder)
The new detailed step has 'Agent Job' settings/parameters, I have the section "Run this job", set to "Only when previous job has failed".
My results have been, that if the previous/default/basic testing passed, the detailed step is skipped. As expected.
But if the previous step fails....the following new detailed step does not kick off.
Is it possible because the step is set up that if it fails hard stop and does not even evaluate the next step?
Or is it because the previous step says 'partially succeeded'. is this basically seen not as a failure?
Yes, this is correct. Because failed is equivalent of eq(variables['Agent.JobStatus'], 'Failed') status. But partially succeeded is eq(variables['Agent.JobStatus'], 'SucceededWithIssues').
Please check here.
You may try custom conditions like :
in(variables['Agent.JobStatus'], 'Failed', 'SucceededWithIssues')
As an addition to the solution, a piece I missed was on the 'detailed' job, the 'Trigger even when the selected stages partially succeed', also needed to be checked, as well as the solution for the same step above.
I am doing some initial one off setup using [BeforeTestRun] hook for my specflow tests. This does check on some users to make sure if they exist and creates them with specific roles and permissions if they are not so the automated tests can use them. The function to do this prints a lot of useful information on the Console.Writeline.
When I run the test on my local system I can see the output from this hook function on the main feature file and the output of each scenario under each of them. But when I run the tests via Azure DevOps pipleine, I am not sure where to find the output for the [BeforeTestRun] because it is not bound a particular test scenario. The console of Run Tests Tasks has no information about this.
Can someone please help me to show this output somewhere so I can act accordingly.
I tried to use System.Diagnostics.Debug.Print, System.Diagnostics.Debug.Print, System.Diagnostics.Debug.WriteLine and System.Diagnostics.Trace.WriteLine, but nothing seems to work on pipeline console.
[BeforeTestRun]
public static void BeforeRun()
{
Console.WriteLine(
"Before Test run analyzing the users and their needed properties for performing automation run");
}
I want my output to be visible somewhere so I can act based on that information if needed to.
It's not possible for the console logs.
The product currently does not support printing console logs for passing tests and we do not currently have plans to support this in the near future.
(Source: https://developercommunity.visualstudio.com/content/problem/631082/printing-the-console-output-in-the-azure-devops-te.html)
However, there's another way:
Your build will have an attachment with the file extension .trx. This is a xml file and contains an Output element for each test (see also https://stackoverflow.com/a/55452011):
<TestRun id="[omitted]" name="[omitted] 2020-01-10 17:59:35" runUser="[omitted]" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Times creation="2020-01-10T17:59:35.8919298+01:00" queuing="2020-01-10T17:59:35.8919298+01:00" start="2020-01-10T17:59:26.5626373+01:00" finish="2020-01-10T17:59:35.9209479+01:00" />
<Results>
<UnitTestResult testName="TestMethod1">
<Output>
<StdOut>Test</StdOut>
</Output>
</UnitTestResult>
</Results>
</TestRun>
My ARM template resource group deployment fails in VSTS.
I get an error without any specific reference to parameter that has an issue: "One of the deployment parameters has an empty key. Please see https://aka.ms/arm-deploy/#parameter-file for details."
The referenced url contain general information, with one comment asking the same question, but no answer to it.
Person asking it alluded that it may have something to do with the version of the deployment step (2.*) and it not using Powershell anymore. I went though the template back and forth comparing parameters in BeyondCompare and nothing sticks out...
Does anyone know what does this error mean?
I had the same issue and found out that some parameters has a space in their values.
So you should write -adminUsername "$(vmuser)".
This works for me
Check Your parameter key or value does not have space in between.
if your value required space then, use "".
check this link.
Example,
direct value -param1 "Value with Space"
value from pipeline variables -param1 "$(valueFromVariables)".
It means you've got a parameterkey in your deployment template without a name. For example "-" instead of "-parametername" or "- parametername" (notice the space).
It can also happen if you manage to paste an 'em-dash' (e.g. from a web browser) instead of a standard dash.
We had the same as matendie; a space between the dash and the parameter name:
- pricingTier "standard"
^ note the space
So, I'm not sure what the issue was, but I gave up on trying to identify the problem, and I deleted the release definition. Recreating it from scratch using the same template, works fine now...
Maybe the definition got some how corrupted.
Not sure, but new one is not having this issue.
Thanks
In my case the problem was with template parameters override. I needed to put parameter value in quotes - "DEV" on screenshot below.
Ran into this the other day. The release pipeline used to be working, and it suddenly started failing continuously with this error:
Error text:
##[error] One of the deployment parameters has an empty key. Please see https://aka.ms/resource-manager-parameter-files for details.
##[warning] Validation errors were found in the Azure Resource Manager template. This can potentially cause template deployment to fail. Task failed while creating or updating the template deployment.. Please follow https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/template-syntax
Starting Deployment.
Deployment name is TemplateDeployment-20220504-******-****
There were errors in your deployment. Error code: InvalidDeploymentParameterKey.
##[error] One of the deployment parameters has an empty key. Please see https://aka.ms/resource-manager-parameter-files for details.
##[error] Check out the troubleshooting guide to see if your issue is addressed: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-resource-group-deployment?view=azure-devops#troubleshooting
##[error] Task failed while creating or updating the template deployment.
Change that caused the error
I had changed the build pipeline such that the build numbers would now have spaces in it: so it changed from my-build-number to my build number. I was still using template param overrides this way: -buildNumber $(Build.BuildNumber):
this would expand to -buildNumber my build number, which breaks the command line processing of the ARM template deployment release task.
Solution
Used quotes for my build number variable: -buildNumber "$(Build.BuildNumber)":
Now this would expand to -buildNumber "my build number", and the Azure Resource Manager (ARM) template deployment release task is happy:
I'm in some trouble with GitLab CI.
I followed offical guide on:
https://github.com/gitlabhq/gitlab-ci/blob/master/doc/installation.md
Everything was ok, no errors nowhere. I followed Runner-Setup, too.
Anything alright.
But...
When I add a runner to a project and then try to build nothing happens.
It could be that I have not fully understood something or some of my configs are wrong.
I'm absolutely new to GitLab CI, but I like it and I want to learn new stuff.
I would be very very glad if someone could help me in some way.
Thanks!
BIG UPDATE:
Just figured out that:
~/gitlab-runners/gitlab-ci-runner$ bin/runner
Starting a runner process manually solves the problem but if I look at the gitlab-ci-runner in /etc/init.d -> it is running !?!
~/gitlab-runners/gitlab-ci-runner$ sudo /etc/init.d/gitlab-ci-runner start
Number of registered runners in PID file=1
Number of running runners=0
Error! GitLab CI runner(s) (gitlab-ci-runner) appear to be running already! Try stopping them first. Exiting.
~/gitlab-runners/gitlab-ci-runner$ sudo /etc/init.d/gitlab-ci-runner stop
Number of registered runners in PID file=1
Number of running runners=0
WARNING: Numbers of registered runners don't match number of running runners. Will try to stop them all
Registered runners=1
Running runners=0
Trying to stop registered runners...kill: No such process
OK
Trying to kill ghost runners...OK
What's wrong here? I'm out of my power or not seeing the problem?!
Problem solved!
You need to edit some values in /etc/init.d/gitlab-ci-runner script!
APP_ROOT="**PATH_TO**/gitlab-runners/gitlab-ci-runner"
APP_USER="**USER_WITH_DIRRIGHTS!**"
PID_PATH="$APP_ROOT/tmp/pids"
PROCESS_NAME="ruby ./bin/runner"
RUNNERS_PID="$PID_PATH/runners.pid"
RUNNERS_NUM=1 # number of runners to spawn
START_RUNNER="nohup bundle exec ./bin/runner"
Now it works!
In my case tags in the runner were different from tags in the .gitlab-ci.yml. Once I changed them so runner tags include all of the config file tests, tasks began to run.