In order to prevent recursive workflow execution Github will not execute workflows triggered by events raised in other workflows.
The known workaround for this is to use a separate Token stored as a secret on the pipeline. However, this means that all subsequent workflows will be run with the user who generate the token and not the user who generated the initial event.
Is there a better way to deliberately trigger workflows via events (i.e. creating a deployment) without having the triggered workflows executed always with the same user?
Related
I am looking for a method to generate a custom webhook callback URL unique to each build within my github action. The purpose of this is that I have a github action which simply starts a test on a server (i.e. browserstack)and returns. It has the option to provide a webhook to call upon test completion.
I ideally would want to somehow generate a webhook custom to this build, and then trigger another action which waits for the webhook callback before continuing. I can always have a polling mechanism which runs every 60 seconds, but I personally prefer to avoid this.
I'm building a CLI which triggers an Action (using workflow_dispatch) in my repository. I'm using Github API to perform this task. Taken from the docs:
You must authenticate using an access token with the repo scope to use this endpoint.
I've generated a PAT with repo scope to authenticate myself. I want users to run this CLI. Is it safe to share this PAT (which has repo as the only scope)?
p.s. I know it is ironical to ask if "Personal"-access-token can be "shared". But I don't see any problem it can cause with its limited scope.
I don't think it is a good idea. Repo scope is not limited to only one repo.
If you want to trigger actions by external users, your best bet would probably be to create a workflow running on PR or Issue events.
Allow your users to create issues
Monitor keywords or label on the issue
Trigger your action.
I have one action that sets the deployment status to success which in turn should trigger another action but that does not seem to work. Isn’t it possible to listen for deployment_status changes in one action that are triggered from within another action?
By design, an action in a workflow run can’t trigger a new workflow run with the default GitHub token. Please refer to the official doc for more details.
Creating personal access token as secrets instead is the workaround.
I have a service hook configured to point to a server which receives a request from Azure Devops every time a pull request is made, which then in turn makes a call to the Azure Devops services REST API to create another pull request.
This second part is done using a PAT (Personal Access Token) for the time being generated from my account. This means that all the pull requests created automatically are made under my name, meaning I receive all the emails and notifications related to this automation.
Is there a way I can create a "fake" identity (without adding an actual user which may authenticate) with a different token which can be used for this automation (opening all pull requests under that identity)?
Is there a way I can create a "fake" identity (without adding an actual user which may authenticate) with a different token which can be used for this automation (opening all pull requests under that identity)?
Short answer is no.
Notification could be setting with three Levels : Origination,project,personal. It is not related with the PAT token.
Based on my experience, the Azure Devops also has no way to know which request is automation or manual way to create PR.
So if you don't want to receive the created PR notification, you could disable it on the personal level.
You also could customize the receive emails with project setting to receive the related information.For more information please refer to this Document.
Is it possible to create a Github Check for pull requests? I know there are WebHooks, but is there a way to also hook into the UI?
Aim:
Pull Request made. Perform validation and update pull request if valid.
Pull Request merged. Create web call to URL. Update Github issue with confirmation.
What's the best way to do this? Is it only via Web Hooks, API calls and getting write oAuth credentials?
Note: you now (August 2018) officially have the notion of Checks
When checks are set up in a repository, pull requests have a Checks tab where you can view detailed build output from status checks and rerun failed checks.
I know there are WebHooks, but is there a way to also hook into the UI?
The recommended way of doing this is to use required status checks and the Status API, in combination with webhooks:
https://help.github.com/articles/about-required-status-checks/
https://developer.github.com/v3/repos/statuses/
Users set up required status checks on the repository so that merging a pull request is blocked if a specific status isn't success.
At the same time, webhooks trigger an external process when a pull request is updated, and that process creates statuses based on the output of that process. If the process completes successfully, then the process should create a success status which will be shown in the UI and unblock the merging of the pull request.
Is it only via Web Hooks, API calls and getting write oAuth credentials?
In order to create statuses, you will indeed need to authenticate with the credentials of a user that has push access to the repository (e.g. via a token from that user with the right scopes).