Within LogicApp I have a parallel branch with run afer set to when fail. If the previous step fails, appropriate actions are taken to mitigate the situation and no more action is needed, nor information on the fail. From business and user perspective that is success, so final Status for the whole LogicApp run shall be Succeeded instead of Failed.
How can I change the LogicApp status to Succeeded?
Or revoke a fail status for particular action (so assume this will solve the problem as well), when I know that it has been mitigated?
This is because the logic apps the engine determines the entire run's status by evaluating all the branch statuses. If any branch ends in failure, the entire logic app run is marked Failed.
The simplest way is add an action after the parallel like the below to add action run after both is successful and is skipped. Cause you already set the parallel action to handle the error and only one branch could be skipped, and with this setting even one branch gets exception failed the logic app still could return fail.
The last action could be any in my test I use a response action, make sure this action will success. And the below is my test, one only one action fail but only one branch is skipped one with one branch failed.
Update with terminate: Check my setting for terminate.
Related
I am triggering a Pipeline from another Pipeline over REST API, which works fine but one thing is annoying me.
I could not find a way to display with queued Pipeline original Commit Message of the Triggering pipeline.
There is a build in variable '$(Build.SourceVersionMessage)' which contains the information I need but I could not find a way to pass this information to triggered workflow so it can be displayed.
Following fields existing the REST API, I though the correct field would be 'triggerInfo' but that didn't changed anything in displayed build message.
Any idea how can I transfer this information and display it?
I have a Web activity that performs a GET operation to an endpoint. I have set it up to do something On Failure (which works just fine) and another set of action upon Success. But this last part gets skipped entirely even though the output of the Web action is Succeeded.
Here is shown the succeeded status and my config
enter image description here
I tried removing and re-adding the On Success connector, but yielded no different results.
Based on your flow, it would never proceed ahead:
Because as per your logic to proceed to the Set run time, Web activity 1 AND Web activity 2 should be success but that can never be the case since web activity 2 can be a success only if web activity 1 has failed thereby not proceeding further.
The below blog explains how to handle this :
https://datasharkx.wordpress.com/2021/08/19/error-logging-and-the-art-of-avoiding-redundant-activities-in-azure-data-factory/
Both dependencies of set runtime status cannot end as succeeded. You need to use a combination of skipped/completed states: https://learn.microsoft.com/en-us/azure/data-factory/tutorial-pipeline-failure-error-handling
From the pipeline image , I think it should move on with success .
Can you please cross check what is status code of web activity and is it returning something back ? Is the status code be 2xx ? If I were you could have tried to check with the "Upon Completion" option and see it works .
So we're having a little bit of a debate where I work as to what point should a reviewer "Approve" a Merge Request.
We have setup some Gitlab Pipelines to run and carry out what I would say are fairly standard stuff (Build, Automated Tests, Sonar etc). Now we're trying to improve best practises across the department and a debate has started as to when the reviewer(s) should actually "Approve" the Merge Request.
We have the 1 argument that says the Pipeline acts as an "Approver" itself and if it fails it basically should prevent the Merge Request from happening, so it doesn't matter when the reviewer(s) hit that "Approve" button, because the reviewer(s) are reviewing the Code and not the pipeline.
And then you have another argument that says the reviewer(s) should not be "Approving" until the Pipeline passes, and they should be dependent on the Pipeline passing as to whether they should be "Approving" the Merge Request or not.
So should the reviewer(s) of a Merge Request wait until the the Gitlab Pipeline finishes and if the pipeline is successful then "Approve" or should they be able to "Approve" once they have reviewed the code, no matter if the pipeline has finished or not?
It's best practice to wait until the pipeline passes, review the code and then do an approval. If the pipeline doesn't pass in the first place, there is an issue and the developer needs to fix his/her PR before someone spends time to review it.
I currently have a task that I intend to run only once when a PR is created. Any pipeline runs due to new commits should not trigger the task. I was wondering if there is a way to detect the runs triggered by changes to code in the PR? When I use the predefined variable $(Build.Reason) I get back PullRequest for both builds(One triggered when PR is created and other when updates are made to PR).
This is what I have in my pipeline and I have enabled build validation for my pipeline.
trigger:
- master
pr:
- master
I don't think there's a way to differentiate the "PR is created" and "PR is updated" build reasons based only on the predefined variables.
However, you can choose a different route depending on what this task you should only run once is. If it is something that can be wrapped into a service with a public endpoint, you can try leveraging the Webhooks.
So, if this is an option for you, try the following:
wrap the functionality required to run only on the PR creation into the service with the public endpoint
create a webhook, choose "Pull request created" event type and enter the public URL of your service
As a result, your build logic won't branch depending on the build reason, and that specific action will be run by the webhook.
I understand it all sounds like a hack and unnecessary complexity, but it's up to you to decide whether it fits your case. At least, this is possible technically.
I would like some automated checks were done after MR is approved, because for those checks pipeline has to access protected variables.
If these checks fail, MR should be rejected.
In other words the desired sequence should be this:
MR created -> build -> run tests -> MR approved (no malicious exposure of protected variables)-> merged to protected branch -> run checks -> rollback on failure.
Is this possible?
You can do this by using the Gitlab API and adding two new jobs at the end of the pipeline.
The when keyword is one of the many ways to control which jobs are executed in a pipeline. Two of the available when options will be useful here. The first job to put at the end of your pipeline will be for the success condition:
approve_merge_request:
stage: approve_merge_request
when: on_success
script:
- # this will call the Gitlab Merge Requests API and approve it. More on this below
This parameter to when is actually the default, so you could leave the when off of this step and it would still work. I added it here for clarity. What it means is that this job will only run if every other job in the pipeline passed. However, if a job fails but has the allow_failure: true attribute, it is still considered a pass and this job will run (there's currently no way to detect that some jobs were allowed to fail in a when condition). In addition, jobs with when: manual that haven't run are considered passed, even though it could later fail. when: manual means the job has to be started by an API call or UI interaction by a user.
The second job will handle our failure condition:
reject_merge_request:
stage: approve_merge_request
when: on_failure
script:
- # this will call the Gitlab Merge Requests API and reject it. More on this below
This parameter to when means that this job will only run if at least one job prior to this has failed, and doesn't have allow_failure: true.
The Merge Requests API can be used to approve, reject, comment on, and merge a Merge Request, among other options. The full documentation is available here: https://docs.gitlab.com/ee/api/merge_requests.html. Unfortunately, the API to use the "approvals" feature of merge requests is available only to paying customers, but you can still get a similar result without the approvals.
You can approve a Merge Request (note, this doesn't merge it, that's "accepting" the merge request. Also, this is a paid feature so is only available to Starter or Bronze customers and above) with the API operation here: https://docs.gitlab.com/ee/api/merge_request_approvals.html#approve-merge-request. After you approve the Merge Request, you probably want to accept it, which will merge the source branch into the target branch. That operation is outlined below.
You can get all of the required ids from the predefined variables Gitlab CI gives you. The project ID can be retrieved from the variable $CI_PROJECT_ID. The Merge Request IID is different from the Merge Request ID. The "ID" version is a unique ID across your entire Gitlab instance, and the "IID" version is specific to the project it's in. For this operation we need the IID. You can get that with the variable $CI_MERGE_REQUEST_IID. You should check that each variable exists before trying to use it as it will cause issues in your API call. It will exist for all pipelines associated with a Merge Request that is open.
There isn't equivalent functionality in Gitlab Merge Requests to "reject" other than commenting and closing, which I outline below.
If you're not a paid customer, or you want to accept and merge the request, you want to use the Accept Merge Request operation here: https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr. This uses the same variables from above.
Finally, if you're not a paid user but still want to "reject" the merge request, you can use the Notes API to add a comment to the Merge Request. The operation to add a comment to a merge request is here: https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr.
After commenting, if you want to close the merge request, you can do so with the Update MR operation and setting the state_event to close: https://docs.gitlab.com/ee/api/merge_requests.html#update-mr