I am trying to execute a github workflow via the CLI, on a particular branch. The documentation for this is available here https://cli.github.com/manual/gh_workflow_run
Is it possible to somehow get the same kind of logs you get with the browser UI in the terminal? I would like to programmatically interact with it.
If its possible with their rest api, then that is even better.
https://docs.github.com/en/rest/reference/actions#create-a-workflow-dispatch-event As per the docs, it just returns a Status: 204 No Content.
It's possible to do trigger a workflow remotely using the Github API with the dispatch_event API you mentioned.
The Github CLI have various command for workflow (to run, list, view, enable ou disable). You can find more information on the official documentation
To get the logs from the Github CLI, as explained here, you can use commands such as:
gh run view run-id --log
Note that if you don't specify run-id, GitHub CLI returns an interactive menu for you to choose a recent run, and then returns another interactive menu for you to choose a job from the run.
You can also use the --job flag to specify a job ID. Replace job-id with the ID of the job that you want to view logs for.
gh run view --job job-id --log
You can use grep to search the log. For example, this command will return all log entries that contain the word error.
gh run view --job job-id --log | grep error
To filter the logs for any failed steps, use --log-failed instead of --log.
gh run view --job job-id --log-failed
Note that you can get a workflow run id from the Github API as well.
Therefore, as you should already have the job_id from the workflow file, it could be possible to start a workflow with a dispatch_event through the API, then get the workflow run_id from the workflow runs list API as well, and use the Github CLI command(s) in loop to get the logs.
It's not pretty, but it should work gathering all those steps in a script as a workaround.
Related
in rasa
my chatbot is not following the story well. Is there a way to collect data about a conversation and see why it chose the story step it chose?
You can add the --debug flag to any CLI command (e.g., rasa shell, rasa run) to get the logs which are going to show you how the intent of the user message is classified as well as the actions predicted by the policies. I would also recommend writing test stories and checking if you get any failures.
I'm new to the whole Azure DevOps world and just got transferred to a new team that does just that.
One of my assignments is to fix an issue with a pipeline where one of the steps runs a shell script that installs an application. Currently, the step seems to run without any issue shown on the log, but when we connect to the container's pod, the app is not there.
If we run the script directly inside the pod, the application is installed correctly. I'm not sure how to track this. One of the things I've tried was to check the event log to see if there's any error while the installation is executed:Get-Eventlog -LogNmae "Windows PowerShell" -Newest 20, so far no luck here. Again, kinda of new at this, not sure what other tools are out there to track the reason why the script is not installing during the pipeline execution.
To troubleshoot your pipeline run, you can configure your pipeline logs to be more verbose.
1, To configure verbose logs for a single run, you can start a new build by choosing Run pipeline and selecting Enable system diagnostics, Run.
2,To configure verbose logs for all runs, you can add a variable named system.debug and set its value to true.
You can also try logging into your agent server and check for the event log. See this blog for view event log on windows.
The issue was related to how the task was awaited. Adding this piped params helped us solve the issue:
RUN powershell C:\dev\myprocess.ps1 -PassThru | Wait-Process;
Hi I have a workflow with 2 activities.
Scenario. one activities is completed while executing second, URL link to which I need to communicate is down. Now when that URL is up workflows is timed out. So How can I restart Timed out workflow?
This question is inspired by a Github issue.
Cadence allows you easily restart any workflow that is already closed in any status: timeouted/failed/canceled/terminated. And even closed with success status: completed or continuedAsNew.
You can use CLI command to reset a workflow to LastDecisionCompleted or FirstDecisionCompleted resetType. LastDecisionCompleted will reset to the last point if you want to save the progress of workflows has made before timeouted. FirstDecisionCompleted will reset to beginning of workflow, like really restarting by saving only the start parameters of workflow:
./cadence workflow reset -w <wid> --reset_type LastDecisionCompleted --reason "some_reason"
If you have many workflows to reset, and your Cadence cluster has advanced visibility feature enabling your search/filter workflows by query, then you can also use batch-reset command like this:
./cadence workflow reset-batch --query <query> --reset_type LastDecisionCompleted --reason "some_reason"
You can also use reset API in client sdk to reset a workflow to a particular point.
Reset is one of the most powerful feature in Cadence for operation. Not only resetting to FirstDecisionCompleted and LastDecisionCompleted, you can easily manipulate workflow to go back to any point of time like using time machine. There are more resetTypes supported if you use "--help" to read the command manual.
Is there any way to find and re-run an earlier instance of a Power Automate workflow programmatically?
I can do this manually: download the .csv file containing the instances, search in the Trigger output column the one I want, get the id, copy-paste the run URL, and click resubmit.
I tried with Power Automate itself:
The built-in Flow Management connector supports only to find a specific flow by name, and does not even go to the history.
PowerShell:
Installed the PowerApps module, I can list the instances with
Get-FlowRun -FlowName {flow name}
But I don't see the same properties as in the exported .csv file, and there's also no Run-Flow command that would let me run it.
So, I am a little stuck here; could someone please help me out?
We cannot programmatically resubmit the Flow run from the history with PowerShell or by any other api method yet.
But can avoid some manual work by using workflow function in a Flow compose step, we can automate the composition of Flow history run url. Read more
https://xxx.flow.microsoft.com/manage/environments/07aa1562-fea6-4583-8d76-9a8e67cbf298/flows/141e89fb-af2d-47ac-be25-f9176e64e9a0/runs/08586722084717816659969428791CU12?backUrl=%2Fflows%2F141e89fb-af2d-47ac-be25-f9176e64e9a0%2Fdetails&runStatus=Failed
There are 3 guids that I need to find aso that I can build up the flow history url.
The first guid is my environmentName (07aa1562-fea6-4583-8d76-9a8e67cbf298), then I’ve got the flow name ( 141e89fb-af2d-47ac-be25-f9176e64e9a0) and finally the run (08586722084717816659969428791CU12).
There is a cmdlet from Microsoft 365 CLI to resubmit a flow run
m365 flow run resubmit --environment flowEnvironmentID --flow flowGUID --name flowRunID –confirm
You can also resubmit a flow run using Power Automate REST API
https://api.flow.microsoft.com/providers/Microsoft.ProcessSimple/environments/{FlowEnvironment}/flows/{FlowGUID}/triggers/manual/histories/{FlowRunID}/resubmit?api-version=2016-11-01
For the Power Automate REST API, you will have to pass an authorization token.
For more information, go through the following post
https://ashiqf.com/2021/05/09/resubmit-your-failed-power-automate-flow-runs-automatically-using-m365-cli-and-rest-api/
I am setting up new builds in TFS 2018 on premise. We need to track the changesets used for our builds.
I have a PowerShell script as a build task that executes TF.exe history command to get the info.
This script runs as long as I execute it from my session but it fails from the build process with a "you are not authorized to access " message. I realize I can add my login info to the command and it will work as expected.
Is there a way to specify that it run as the local system? The user is runs under now is "machinename$"
You could do it by running
tf /loginType:OAuth /login:.,$env:SYSTEM_ACCESSTOKEN
But you have to allow access to token on the build agent phase.
Edit your build definition, click on the options view. There you will find the field to allow token access.