I have CruiseControl.NET setup to send out an email if there is a compile error and when the error has been fixed:
<notifications>
<notificationType>Change</notificationType>
</notifications>
However this also sends out an email if the source code repository can't be reached. This is expected since the server is restarted every night.
How can I limit the alert emails to compile errors only?
this also sends out an email if the source code repository can't be reached
You can use the sourceControlErrorHandling tag (action to take when a source control error occurs)
<maxSourceControlRetries>3</maxSourceControlRetries>
<sourceControlErrorHandling>ReportOnRetryAmount</sourceControlErrorHandling>
Setting ReportOnRetryAmount to a high value will lower your exception build email.
Reference: 'Project Configuration Block' documentation.
http://www.cruisecontrolnet.org/projects/ccnet/wiki/Project_Configuration_Block
I don't think CC.NET is able to distinguish a "usual" build failure from source code unavailability. The notification type can be one of the following: {'Always', 'Change', 'Failed', 'Success', 'Fixed', 'Exception'}. I'm not sure I can tell the difference between Failed and Exception - probably, the first is a build failure, including unit test failure, etc., while the other one refers to the CC.NET own code failure.
Anyway, if I were you, I would do one of the following:
experiment with notification types (just in case)
make sure the build process is not triggered when the server is restarting, e.g. if you configured nightly builds, you can schedule those to run after the server restarts
Related
We are experimenting with Design automation for Revit and have gotten stuck on a failure that is hard to debug:
basically our code finish and then forge takes over and fails.
Here is part of the log: I have marked in green what part are "our" logs:
Basically the app takes an rfa and should output a json.
I have defined the activity like this:
What can I do to investigate what is causing this issue?
I found the issue:
you need to explicitly set the Succeeded property to true on the DesignAutomationReadyEventArgs. Otherwise it will report as failed.
I'm using Azure's Runs API to get a pipeline run result as described here:
https://learn.microsoft.com/en-us/rest/api/azure/devops/pipelines/runs/get?view=azure-devops-rest-6.0#runresult
I can see in the documentation how to get the state and final result so I can know if the run was a success or a failure. However, in case of a failure, I don't see how I can get the error that occurred in that run as a string.
How can I get the actual error which caused the pipeline run to fail?
You can use the REST API "Timeline - Get" to list the issues (error and warning) associated with a run.
Note:
This API can only list the first 10 issues. If the run has more than 10 issues, the rest will not be listed in the response. To get the complete issues, you can use the API "Builds - Get Build Log" or "Logs - Get" to get the complete logs that contains the complete issues.
[UPDATE]
The buildId is same as the runId, and you can find it from the URL of the pipeline (build) run.
The timelineId is not required in the API request, you can use the request URI like as below.
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/timeline/?api-version=6.0
I'm new to using Azure DevOps. I continue to receive this error "Add-PnPApp : The request message was already sent. Cannot send the same request message multiple times."
Azure DevOps Release fails because of AddPnP error with "...same request".
Build shows version that changes my version (old) to a new version(gulp's version?).
Image of build
I'm told that it could be the version that starts with zero because SharePoint doesn't like it. I can't seem to change the new version to 1.0.0.1 because it seems like it's being changed in the gulp-file.js. Is there something else that I am missing?
image of release
Is it possible that you need the overwrite parameter in the AddPnP command? Or is it possible you would need to iterate the version between each release?
https://learn.microsoft.com/en-us/powershell/module/sharepoint-pnp/add-pnpapp?view=sharepoint-ps
In my case the same message
The request message was already sent. Cannot send the same request message multiple times
was misleading. I tried to update dynamically an .sppkg package (which is in fact a ZIP file) during an automated deployment, but the file _rels/.rels was getting lost in the process (because of the bug Unable to compress hidden files with Compress-Archive) and the resulting package was corrupted.
Once I fixed the package by making sure the file _rels/.rels was kept, the deployment would succeed.
In Liferay, I see the following error:
Problem: Absolutely nothing appear in the Liferay log
Question: How to investigate further?
For some obscure reason, Liferay has chosen to make some exceptions (even very serious ones) show up with the DEBUG log level.
So, the solution is to set the log level to DEBUG (The com.liferay package should be enough for most situations):
Don't forget to press "Save". Once set, try again (no restart needed), and you will probably see the exception appear, so that you can know exactly what is going wrong.
Example:
09:34:29,903 DEBUG [http-nio-8080-exec-5][LiferayPortlet:587] com.liferay.asset.kernel.exception.NoSuchEntryException: No AssetEntry exists with the key {classNameId=20015, classPK=36354}
com.liferay.asset.kernel.exception.NoSuchEntryException: No AssetEntry exists with the key {classNameId=20015, classPK=36354}
at com.liferay.portlet.asset.service.persistence.impl.AssetEntryPersistenceImpl.findByC_C(AssetEntryPersistenceImpl.java:3551)
This log level modification will be reset next time you restart Liferay.
To get more information on an unexpected "Your request failed to complete" error, you can activate the DEBUG traces for the category:
com.liferay.portal.kernel.servlet.SessionErrors
on the Control Panel => System => Server Administration => Log levels section.
After activating these DEBUG traces, every time an error is stored in the SessionErrors object, it will be written to the log file.
These traces were added by the LPS-135569 issue that was fixed as of DXP 7.4, so if you are using an older version, you will have to update or patch your installation.
We're using Puppet + Foreman to monitor changes in environment by checking custom facts. For example, whenever a custom fact equals 'true' puppet calls the Notify resource with a message sent to the agent log. Puppet includes this message in the agent report and Foreman shows this in UI.
Problem is that whenever a message is thrown, Foreman considers this action as "Applied" and the node status changes to "Active" (blue icon).
We want to keep the node at "No Changes" (Green) plus show the Notify message.
Is that possible in some way? Maybe define a new custom resource type?
Here is the puppet code:
class mymodule::myclass::mysubclass {
if $::fact023 == 'fail' {
notify {'mynotify1':
message => "WARNING: Node ${::fqdn} failed fact023",
loglevel => hiera('warnings_loglevel'),
} } }
See screenshot of Foreman here
Update:
I'll refine the question: Is there a way to use the Notify resource without causing puppet to report that the node has changed? Meaning just print the message to client log (and therefore the message will be visible in report) but without puppet classify the event as an applied configuration?
The reason is that when puppet triggers the Notify resource, Foreman flags the node as being active (changed)
UPDATE #2
I'm thinking about changing Foreman report file so that the UI will ignore Notify events so that the node's status will remain unchanged but still show the message in the report. Can someone point me to the right direction? Thanks!
UPDATE #3
Problem fixed after switching from the "Notify" resource type to custom type "echo" created by some dude in Puppet Forge. Thanks!
It's not completely clear what you are trying to accomplish. One option would be to use the notice function instead of a resource. Functions execute on the puppet master, so you the log will end up in the puppet master's logs instead of the agent report. That also means that it will not count as an applied resource, and the node should appear to be stable.