According to Yarn document, YarnApplicationState is the state of application reported by ResourceManager, while FinalStatus is the final status of application reported by ApplicationMaster itself.
Sometimes while YarnApplicationState is SUCCEEDED, FinalStatus of the application could be FAILED.
So what's the difference between these two status? And which one can decide whether the task is executed successfully?
The Resource Manager reflects the Application's status regarding YARN answering the following question:
Did the application complete properly? Did all the mapper and reducer tasks complete?
While the AM's FinalStatus can reflect whether the application's purpose succeeded answering the following question:
Did it produce the right output? Was it able to write output to HDFS?
Related
SonarQube: Enterprise Edition Version 9.2.4 (build 50792)
Sonar client: 4.7.0.2747
Scan is launched for merge request in gitlab. I am requesting coverage for pull request.
Imidietly after scan (using scanner client) is finished I try to get coverage by following call:
http:///api/measures/component?metricKeys=coverage&component=&pullRequest=
I am getting:
404 : “{“errors”:[{“msg”:“Component \u0027u0027 of pull request \u0027\u0027 not found”}]}”
Interestingly if I put some sleep (1 second) after scan is finished and before i do a call to get coverage everything is fine.
It seems it has to do something with the fact that it’s a new pull request and regardless scan is finished and it generates link with results, it still requires some time before it will be possible for the api call i mentioned to be able to return coverage. Also, if i retry the operation(scan and get results) on already existing pull request there are no issues like this.
Could you please elaborate on this issue, is such behavior is expected or maybe there are some other ways I can get coverage right away after the scan is finished without adding any sleeps…
As a side observation under same circumstances if i do scan on new pull request and call another api (/issues/search?) to get list of detected issues and it successfully works without any additional sleeps,
Thank you.
After the call from the scanner client completes, SonarQube executes a "background task" in the project that finalizes the computations of measures. When the background task is complete, your measures will be available. This is why adding a "sleep" appears to work for you. In reality, it's just luck that you're sleeping long enough. The proper way to do this is to either manually check the status of the background task, or use tools that check for the background task completion under the covers.
If you're using Jenkins pipelines, and you have the "webhook" properly configured in SonarQube to notify completion of the background task, then the "waitForQualityGate" pipeline step does this, first checking to see if the task is already complete, and if not, going into a polling loop waiting for it to complete.
The machinery uses the "report-task.txt" file that should be written by the scanner. This is in the form of a Java properties file, but there's only one property in the file that you care about, which is the "ceTaskId" property. That is the id of the background task. You can then make an api call to "/api/ce/task?id=", which returns a block that tells you whether the background task is complete or not.
In one of the workflows, task notification has been sent to an user's inbox. When the user tries to acquire the task, he is getting the error like missing package for the current task of the workflow.
Kindly provide me the suggestion on resolving this issue.
During the Workflow definition if the Package is added as Mandatory Package, and during task completion process if the task attachment is missing, user is expected to get this message in D2 client.
Please check weather the Task attachment is missing from repository in this scenario.
You can either:
Verify if the associated activity definition for the task (from process builder for example) has defined correctly the package/s.
or
Verify if the attached object (document/s or folder/s) to the task exists in repository or the user has at least BROWSE permission on it.
Also, a good idea is to check the D2 app server and JMS logs.
I have created a simple state-machine workflow in youtrack to reflect our process. It uses three State values (Submitted, In Progress, Fixed) and allows to move through them sequentially.
Is it possible to restrict certain state changes for specific roles? For example role Reporter should only be able to create issue and move from 'Fixed' to 'In Progress' if something is wrong.
UPDATE:
An even better way to do this task is the following right inside the Statemachine:
initial state Submitted {
on Approve[always] do {
assert loggedInUser.hasRole("Project Admin"): "Only Project Admins can Approve tasks.";
} transit to Open
}
OLD ANSWER:
Straighforward way (inside the Statemachine itself):
initial state Submitted {
on Approve[loggedInUser.hasRole("Project Admin")] do {<define statements>} transit to Open
}
Althought it will work, it will fail silently, so user will not know why does it not work.
A much better approach will look like the following (for this you will have to create Stateless Rule):
when State.oldValue == {Submitted} && State.becomes({Open}) {
assert loggedInUser.hasRole("Project Admin"): "Only Project Admins can Approve tasks.";
}
In this case user will get an error message that you specify.
Remember to delete the condition in the Statemachine, since it is checked earlier and you will not have any error messages as assertion will not run at all.
A pretty old question, but I'll try to answer.
You can specify a guard expression that will be invoked upon transition to/from a specific state. In this expression you can validate user permissions.
I have Jenkins project that perform some sort of sanity check on couple of independent documents. Check result is written in JUnit XML format.
When one document test fails, entire build fails. Jenkins can be simply configured to send email to commiter in this situation. But I want to notify commiters only when new test failed or any failed test was fixed with the commit. They are not interested in failed tests for documents they have not edited. Email should contain only information of changes in tests, not full test report. Is it possible to send this kind of notification with any currently available Jenkins plugins? What could be the simplest way to achieve this?
I had the same question today. I wanted to configure Jenkins sending notifications only when new tests fail.
What I did was to install email-ext plugin.
You can find there a special trigger that is called Regression (An email will be sent any time there is a regression. A build is considered to regress whenever it hasmore failures than the previous build.)
Regarding fixed tests, there is Improvement trigger (An email will be sent any time there is an improvement. A build is considered to have improved wheneverit has fewer failures than the previous build.)
I guess that this is what you are looking for.
Hope it helps
There's the email-ext plugin. I don't think it does exactly what you want (e.g. sending only emails to committers who have changed a file that is responsible for a failure). You might be able to work around that/extend the plugin though.
Also have a look at the new Emailer, which talks about new email functionality in core hudson that is based on aforementioned plugin.
I was wondering if there was a way to do this in Hudson (or with any of the various plugins). My IDEAL scenario:
I want to trigger a build based on a job through a REST-like API, and on that build, I want it to return me a job ID. After-wards, I would like to poll this ID to see its status. When it is done, I would like to see the status, and the build number.
Now, since I can't seem to get that working, here is my current solution that I have yet to implement:
When you do a REST call to do a build, its not very REST-ful. It simply returns HTML, and I would have to do a kind of parsing to get the job ID. Alternatively, I can do a REST call for all the history listing all the jobs, and the latest one would be the one I just built. Once I have that, I can poll the console output for the output of the build.
Anyone know a way I can implement my "ideal" solution?
Yes, you can use the Hudson Remote API for this (as #Dan mentioned). Specifically, you need to configure your job to accept Remote Triggers (Job Configuration -> Build Triggers -> Trigger builds remotely) and then you can fire off a build with a simple HTTP GET to the right url.
(You may need to jump through a couple additional hoops if your Hudson requires authentication.)
I'm able to start a Hudson job with wget:
wget --auth-no-challenge --http-user=test --http-password=test "http://localhost:8080/job/My job/build?TOKEN=test"
This returns a bunch of HTML with a build number #20 that you could parse. The build number can then be used to query whether the job is done / successful.
You can examine the Hudson Remote API right from your browser for most of the Hudson web pages that you normally access by appending /api (or /api/xml to see the actual XML output), e.g. http://your-hudson/job/My job/api/.
Update: I see from your question that you probably know much of what I wrote. It is worth exploring the built-in Hudson API documentation a bit. I just discovered this tidbit that might help.
You can get the build number of the latest build (as plain text) from the URL: http://your-hudson/job/My job/lastBuild/buildNumber
Once you have the build number, I think the polling and job status is straightforward once you understand the API.
And what if you don't want the latest build number, but you want the build number of the build that was triggered by hitting the build URL ?
As far as I can tell, hitting that URL returns a 302 that redirects you to the job's mainpage, with no indication whatsoever of what the build number is of the one that you triggered.