In a repository we have :
a workflow that runs on: pull_request
so it runs each time I open/ commit to the pull-request (which I opened)
we have an action (runs manually) that commits to the pull-request (updating some files in the branch)
when the second action finishes to run, I can see its commit on the pull request
but it doesn't trigger the first workflow to run again
(in order to run the workflow after the action's commit, I need each time to insert a dummy commit or close and re-open the pull-request)
Is there another way to trigger the first workflow after a "bot" from the 2nd github action commits?
Don't do that. GitHub generally "dislike" having workflows trigger other workflows, for the obvious reason.1 Instead, write a reusable workflow, then use and re-use it.
See also Github Actions - trigger another action after one action is completed.
1If the reason isn't obvious, see this question. Follow the link until it becomes obvious why this is a bad idea. (In Computer Science, see the definition of recursion. In Philosophy, a closely related idea is called Begging the Question.)
You could add push trigger as well to the workflow as follows:
on:
- push
- pull_request
It should then run the workflow when you push a commit or tag. See docs here.
Related
I am working on a repo where I am the owner and only author in it.
I want to have in my repo the same behavior as I would when working with a team that protects my branch from direct commits as they must go through a Pull Request. The reason for doing so is to protect from my own mistakes as I sometimes go back to main branch and accidentally push code to it. I want only code that passed through a Pull Request to be able to be merged to main branch.
In order to achieve such behavior I added the following rule to my main branch -
Which is almost what I need, expect that I am locked without the ability to approve my PR's as there is a message I get saying authors of the PR can't approve their PR's - a logical error nonetheless, but if I am working alone in the repo this is not what I am looking for.
How can I achieve what I am looking for?
Simply disable "Require approvals" (the second checkbox in your screenshot), you will still be required to create a PR.
You can merge your own PRs, the only thing you cannot do is to approve your own work (after all: why would you? Hopefully you deem your own changes good!)
I'm using GitHub actions to automate pull requests to my repositories. In particular, I'd like to run actions whenever a pull request gets a review to automatically label it. Because of this, I'd like to run code from the context of my base branch (similarly to how pull_request_target works as a counterpart to pull_request).
I've looked at the events, but there doesn't seem to be a pull_request_review_target or any similar events that would be the counterpart to pull_request_review.
And what's about submitted on pull_request_review
on:
pull_request_review:
types: [submitted]
Or maybe I misunderstood you
Is it possible within GitHub Actions to mark a workflow as something that is not a check? I can't find a hint inside the (good) documentation unfortunatly
I have included two default workflows to label pull requests and to greet first time contributors, but i don't want those workflows to be listed as "checks" since they aren't checking anything.
See here: https://github.com/wujood/awesome-gamejam/pull/3
It looks like it's not possible if you're triggering on the pull_request event. As a workaround you could try using a schedule or another event as a trigger.
As per https://github.blog/changelog/2019-09-24-ui-changes-in-github-actions-checks/ they explicitly changed the UI to don't display some checks.
GitHub Actions uses the Checks API for representing and storing information about job executions.
[...]
At the same time, Actions can be triggered not just when somebody pushes code to GitHub but when many other events occur. In these cases, GitHub Actions looks for workflow files in the default branch of the repository and creates and associates the checks with the SHA of the latest commit.
[...]
We have found that this can be noisy and not relevant in the context of a pull request. It can also cause friction when protected branch rules are enabled. As of today, we’re deploying a change to remove checks generated due to events other than push and pull_request from the context of pull requests or in the calculation of commit statuses. These checks will be available in the Actions tab for observability.
(emphasis mine)
And also:
GitHub Actions use the Checks API to output statuses, results, and logs for a workflow. GitHub creates a new check suite for each workflow run. The check suite contains a check run for each job in the workflow, and each job includes steps.
source: https://docs.github.com/en/free-pro-team#latest/actions/managing-workflow-runs/using-workflow-run-logs
There is also the following closed issue corresponding to the UI change described above: https://github.com/actions/toolkit/issues/86.
For a variety of reasons, I need to manually trigger a GitHub Actions run from a comment on a PR mentioning a bot (I’m using ProBot). I figured out how to start the workflow by setting the start to on: workflow_dispatch and calling the API. Where I’m running into an issue is linking the run to the PR. Right now, the action just starts and completes without ever appearing in the checks section of the PR.
I noticed that there is a checks create method on the API, but it seems more geared towards making your own check suite. I could use that to create a check run, manually watching the GitHub Actions process, and appropriately updating the check run, but it seems like overkill. I haven’t seen anything in The API that would allow this to happen. There may be a way to do it from the action itself too, but I haven’t found anything.
I don't think you can use workflow_dispatch to add/update checks on a PR. This seems to be confirmed by this response to a similar question on the community forums.
Checks are only added/updated for the following events:
pull_request
pull_request_review
pull_request_review_comment
pull_request_target
push
So your manual operation needs to trigger one of these events to run. There are probably a number of different ways you can do this, depending on your use case. Just as an example, you could call the API to add a label and allow a pull_request workflow to execute on that type.
on:
pull_request:
types: [labeled, opened, synchronize, reopened]
The other thing to note is that the API call (or git push) must use a PAT instead of GITHUB_TOKEN. This is to allow further workflows to execute.
It is possible with some workaround. First, you have to identify the PR that invoked your workflow. If you need to use the workflow_dispatch trigger event, you can pass this PR number as input parameter. Otherwise, you mentioned you trigger this workflow on a specific comment so you could also use the issue_comment event which will give you the PR number as github.event.issue.pull_request.
Next, you have to find out the latest commit of this Pull Request. This depends on how your workflow got invoked:
if you use the issue_comment event, you can use the xt0rted/pull-request-comment-branch action to determine the right branch and commit
if you use the workflow_dispatch event, you can use the actions/github-script action to run some query to get the right commit for a given PR number
Finally, you can use the myrotvorets/set-commit-status-action action to attach the workflow result as check on the latest commit of the PR.
I wrote a blog post that describes this process in some more details: Trigger GitHub Workflow for Comments on Pull Request
My goal for Jenkins is to trigger a build from a github branch automatically, build the application, make a update to the source and then push the source update to the same branch.
All is working except I find myself in a loop. I'm using the build trigger "Build when a change is pushed to GitHub".
When I push the update to the same branch from within the job, it then triggers the build again putting the whole process into a loop.
What I'm looking to do is somehow put this trigger on hold until the whole job is complete.
(I happen to be building an xcode project and updating the build version number in the plist... not sure that is directly relevant to the problem at hand)
When I push the update to the same branch from within the job, it then triggers the build again putting the whole process into a loop.
Then it would be best to push to a different branch, considering that, even if the GitHub webhook fires again, at least it will fire a JSON payload, with, for the push event, with a different branch name
ref string The full Git ref that was pushed. Example: “refs/heads/master”
By checking the name of the branch push in that payload, you will be able to avoid the loop.
I found myself in the same conondrum, and found the answer:
https://liviutudor.com/2015/12/09/jenkins-ci-trick-to-prevent-task-from-triggering-itself-on-scm-commit/#sthash.j7YTr3l0.dpbs
Basically you can choose the option "Polling ignores commits from specific users", and add your bot's username =]
Simple & elegant