Project

General

Profile

Feature #3561

Getting error information in job Failure branch

Added by Vadim about 1 year ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
RapidDeploy - 5.0-FIX
Start date:
06/02/2020
Due date:
% Done:

0%

Estimated time:
Affects Version:
RapidDeploy - 5.0-FIX
Timesheet Code:
Additional version details:
5.0.24

Description

Hello again.

Making automated deployment pipeline I added Failure branches to project job plan. Those branches call project that sends e-mail to inform about failed deployment. Is it possible to get out any information about the occurred error in job plan or project? It could be great to send informative error message.

Best regards,
Vadim.


Related issues

Related to RapidDeploy-Community - Feature #3573: Getting user data in deployment projectClosedVadim06/17/2020

Actions
#1

Updated by Rafael about 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Rafael
  • Target version set to 5.0-FIX
#2

Updated by Rafael about 1 year ago

Hi Vadim,

It is possible to retrieve the logs of a deployment by making a GET request to the following URL:

http://RD_HOSTNAME:RD_PORT/MidVision/ws/streamer/job/log/${JOB_ID}

I'm now trying to figure out how you can get the job ID from inside the orchestration.

I'll keep you posted with any update here.

Cheers!

Rafa

#3

Updated by Vadim 12 months ago

Hello Rafael.

Any news regarding this issue?

Seems that I posted new one ticket that is slightly related to this one - ticket about how to get user info in a task.

Will be waiting for Your update. :)

Best regards,
Vadim.

#4

Updated by Rafael 12 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from Rafael to Vadim

Hi Vadim,

This is indeed related to #3573.

We're now investigating the best way of retrieving the job ID during the orchestration execution. I'm not sure if this is even something feasible, but Mariano is now investigating all the possible options.

In the meanwhile, do you know about the automatic email notifications?

You can find some information here:

http://docs.midvision.com/LATEST/reference/administration/configure-email.html

And they are different automatic notifications if the deployment fails, is successful, halted, or some other situations. They are sent to the user that requested the deployment and contain some basic information and a link to the job log.

Maybe this is the solution for this and #3573! :-)

Let me know if you need any further help or better explanation.

Cheers!

Rafa

#5

Updated by Vadim 11 months ago

Hi Rafael,

Thank You for the reply. After Your message I configured e-mail settings on RapidDeploy server and everybody now get lots of mails about job execution. :) Not all are really happy. :) Therefore have question: maybe it's possible to reduce mail count for certain users? Our deployment pipeline consists of several intermediate deployments and package creations, so user gets several Success mails at once and only the last one is the final. :) It could be great to be able not to send some mails for some users.
And, by the way, question about getting some technical information inside the running job plan is still open. :) Of course, there is no need to have both standard RD information sending and custom one.

So resuming all written above. There is no need to get technical information inside a job plan when using standard RD information system. This question can be closed. But there is another question regarding possibility to switch off some mails to certain users. Is it possible?

I even could say better: is it possible to setup system so that some users (admins) get all e-mails (from all users) and some users (simple users, developers) get only one e-mail with deployment results (success, fail, details)? :)

Best regards,
Vadim.

#6

Updated by Rafael 11 months ago

  • Assignee changed from Vadim to Mariano

Hi Vadim,

Unfortunately this ticket and #3573 depend on #3574 (internal issue, you may not be able to see it), that is basically a new feature to obtain the RapidDeploy user that requested the job and the job ID from within the orchestration execution as built in variables (http://docs.midvision.com/LATEST/project/built-in-variables.html), something like ${JOB_ID} and ${RD_USER}.

This is definitely in our roadmap but we still need to study the feasibility of this new feature, as it could just be out of our scope to implement this.

Regarding the email notification system, I'd say there is no way of filtering the emails that you receive, but let's see if Mariano can give you a better answer as I'm not completely sure about this.

As a workaround you can always use the filtering system of your email client, but I'm aware that's not exactly what you are looking for. :-)

Anyway, let's see if Mariano can give us a finer explanation.

Cheers!

Rafa

#7

Updated by Mariano 11 months ago

  • Assignee changed from Mariano to Vadim

Hi, I think email notification system is quite simple, you set a valid email in each user and the SMTP server is configured correctly, all is send... otherwise it is not.

You have also a way to configure email by project, it sends a basic project finish job status. This settings are in the project details page, Orchestration tab -> Settings tab. There, you can configure separatelly by project the email notification.

I am afraid there in no mucho more options to do right now. So, depending on your needings, you can disable completely the emailing feature just not setting the RD smpt configuration in rapiddeploy.properties, or enable the smtp in RD properties but setting some user with the right emails and another users with a fake email or point at , or set an email listings alias like , where the user that need to be notified are included. Additionally you can set the project email notification.

Let me know if there is any doubt.

Regards,
MP

#8

Updated by Rafael 10 months ago

  • Status changed from Feedback to In Progress
  • Assignee changed from Vadim to Rafael
#9

Updated by Rafael 9 months ago

  • Status changed from In Progress to Resolved
  • Assignee changed from Rafael to Vadim

Hi Vadim,

So finally this feature is out! :-)

We've implemented a new built-in variable that you can use in the orchestration. You can see it in our SNAPSHOT documentation although it is not officially released:

http://docs.midvision.com/5.0.24-SNAPSHOT/project/built-in-variables.html

It is the "${JOB_ID}" variable.

In your case you can use the "REST Service Call" task to make a GET call to the following URL:

http://RD_HOSTNAME:RD_PORT/MidVision/ws/streamer/job/log/${JOB_ID}

And get the full deployment log of a certain RapidDeploy project deployment.

This particular call does not need authentication, so you basically just need to set the URL in the task as in this example:

restServiceURL = http://localhost:9090/MidVision/ws/user/${JOB_USER}

It probably does not make much sense to retrieve the deployment logs inside the current deployment, but you can always have a final or failure project to retrieve this information, which I actually think was your intention from the beginning.

The idea is you pass the particular job ID along the job plan to the reporting project using the global job plan variable tasks: "Set Job Plan Variable" and "Get Job Plan Variable".

http://docs.midvision.com/LATEST/rapiddeploy-orchestration/resources/tasksMetaData.html#d1e7458
http://docs.midvision.com/LATEST/rapiddeploy-orchestration/resources/tasksMetaData.html#d1e7369

This feature is not yet out and will be released with RapidDeploy 5.0.24, but you can already start thinking about how to apply it.

I hope it is useful! :-)

Cheers!

Rafa

#10

Updated by Rafael 9 months ago

  • Tracker changed from Support to Feature
#11

Updated by Rafael 8 months ago

  • Additional version details set to 5.0.24
#12

Updated by Rafael 8 months ago

  • Status changed from Resolved to Marked for Closure

Hi Vadim,

RapidDeploy 5.0.24 is already out, if you don't have anything else to add in this ticket we'll just close it in a few days time. :-)

Cheers!

Rafa

#13

Updated by Rafael 8 months ago

  • Status changed from Marked for Closure to Closed

Also available in: Atom PDF