UseCase: My current use case is to react on new Issues and post automatic comments. This is mainly specific to one or two repositories.
Thus I guess webhooks on a repository as well as Github Apps can be used. Although Github has some really good documentation on both, I'm unsure which one to use for my scenario.
What advantages / disadvantages do they have when compared?
One advantage of Github Apps is that they don't need to add a WebHook to the repository according to this answer. - Not sure why that is an advantage.
Obviously a GitHub App can be installed in different repositories and also published in the marketplace. But I could also use the same URL for Webhooks in different repositories and thus mimmic that behavior with repository-webhooks to a certain extend.
What else?
The main difference is that while webhooks generate events and send them to a given URL Github. Apps have the right to access the repositories where you install them based on the permissions you give them.
If you have a webhook that fires every time an issue is updated you will receive an event at the URL you specified, but you will not have any rights to e.g. modify that issue in Github (e.g. through an API call).
If you instead have a Github App installed in your repository and the webhook URL set in the App settings, then the event will be sent to the URL as well. However, here's the difference: behind the webhook URL you will probably have a service that uses the Github App credentials (private key or temporary tokens) to make some modifications to your Github repo.
An example:
Webhook -> logging of Pull Request changes
Github App -> automate tagging of new pull requests
What else?
You can also use GitHub Actions. For your use case, there is the issues event (which is actually a webhook). It has several activity types, including opened:
on:
issues:
types: opened
This workflow only runs when an issue is created. Afterwards, you can use the REST API (e.g. via curl) to GET the newest issue and POST a comment.
As you said this is only relevent for "one or two repositories", I think it is fine to just copy & paste that workflow. If the number of repos grows, you may want to create a dedicated action.
Speaking of custom actions, there is also an existing Auto Comment action:
on: issues
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: bubkoo/auto-comment#v1
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
issuesOpened: >
Your issue comment goes here.
Related
How can I add a custom button on GitHub.com which I could click on in order to deploy changes from the Master branch to a related Salesforce.com DEV Org?
What have you tried? Have you seen https://developer.salesforce.com/blogs/2020/01/using-salesforce-dx-with-github-actions ?
You can steal sample actions from SF official repo at https://github.com/trailheadapps/lwc-recipes.
You'll need to provide the secret login URL to your target org, there are blog posts how to generate it and store in GitHub variable, for example https://tigerfacesystems.com/blog/sfdx-continuous-integration/ or https://github.com/sfdx-actions/setup-sfdx
Last but not least - to have action available for manual run (not just automated) read up about "workflow_dispatch"
I have Repo A (private, in an organization), which has a GitHub Actions workflow that builds and bundles my application into a tar.gz file and includes it as an artifact in a Release.
I have Repo B (also private, same organization) which, in the GitHub Actions workflow, needs to download the release artifacts from a specific release of Repo A, and do other things with it.
What is the modern best-practices approach to enabling this cross-repo release access within an organization? Last time I did this, we had to use a Personal Access Token for a machine user that we created, which is all sorts of bad (machine user GitHub account, long-lived secret, etc.). GitHub has since added a lot of capability with the built-in GITHUB_TOKEN secret, with OIDC support within Actions, etc. Is there a better way to achieve what I'm trying to do?
If you are using a Linux Docker container, you can try and use dsaltares/fetch-gh-release-asset which is meant to:
downloads an asset from a GitHub release and provides some release details as output.
Private repos are supported.
You can find an example here.
But it does use a GitHub token which defaults to ${{ secrets.GITHUB_TOKEN }}: make sure it is a GitHub App installation access token.
I couldn't find much about whether "unpublishing" a GitHub Action from the Marketplace is possible, as of Dec, 2020.
There is a lot of doc regarding "how to publish", but couldn't find anything about unpublishing.
Am I using a bad keyword? Am I understand how publishing work correctly? I had assumed published actions are different from public actions available on GitHub directly, but I'm not so sure anymore.
Also, I read https://julienrenaux.fr/2019/12/20/github-actions-security-risk/, which basically states there is a huge security issue by blindly using something like peter-evans/create-or-update-comment#v1 without using a specific hash. But I haven't seen use of hashes anywhere so far.
Here is an example of code that we actually use in our company, in our GitHub Action:
# On E2E success, add a comment to the PR, if there is an open PR for the current branch
- name: Comment PR (E2E success)
uses: peter-evans/create-or-update-comment#v1
if: steps.pr_id_finder.outputs.number && success()
with:
token: ${{ secrets.GITHUB_TOKEN }}
issue-number: ${{ steps.pr_id_finder.outputs.number }}
body: |
:white_check_mark: E2E tests **SUCCESS** for commit ${{ github.sha }} previously deployed at [${{ env.VERCEL_DEPLOYMENT_URL }}](${{ env.VERCEL_DEPLOYMENT_URL }})
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Basically, the above article states using peter-evans/create-or-update-comment#v1 is dangerous, because anybody can publish against the v1 tag and update the v1 version we're using, without us even noticing such a change. (And, from there comes all sort of dangerous thoughts, such as Secrets stealing)
The article is 1 year old, maybe things have changed since then? It's hard to believe GitHub would leave such a security hole at the heart of their Actions Marketplace. I never heard of it before and I'm quite shocked/concerned about that.
So, there were 2 questions at hand:
What is the role of the GitHub Actions Marketplace?
How to unpublish an action published in GitHub Actions Marketplace?
About 1), unlike what I assumed, the role of the Marketplace is limited to indexing GitHub Actions, so that they're easier to find. It's very different from NPM, which is to secure the published packages so that no one can temper with them.
Because Actions are referenced using their GitHub path, an author can destroy their own action any time. Deleting their repository or marking it private are actions that will break all existing integrations right away.
Short story: Forking and referencing actions you use using their hash/SHA is the only way to build resilient actions that won't break your CI when someone changes their branch/tag, or delete/hide their GitHub repository.
Long story: See https://github.com/UnlyEd/next-right-now/discussions/223
About 2), by "unpublishing" an Action from the Marketplace, what you really do is "deindex" it, that's all. You don't destroy anything nor break any workflow, you only remove it from the marketplace, and it won't be shown anymore.
You can do so by editing your releases (on GitHub) and uncheck the "Publish this action to the GitHub Marketplace".
See https://docs.github.com/en/free-pro-team#latest/actions/creating-actions/publishing-actions-in-github-marketplace#removing-an-action-from-github-marketplace
This seems to be one of the more important, but less understood and documented features of GH and Jenkins, which seems to defeat the purpose of CI entirely ...
I'm trying to setup a simple, "kick off a build when a pull request is opened" Job in Jenkins. I've scanned though dozens of posts, some several years old, but have yet to find a solution that actually works, start-to-finish. I'm using GH 2.15.4 and Jenkins 2.89.3 with the GH Pull Request Builder plug-in. I've tried setting up a pipeline job, and a freestyle project, following various "how to" posts and docs. Nothing works as expected. Not even close. I've managed to get some functionality working, but not without a lot of trial-and-error experimenting, which doesn't leave me with a warm-fuzzy in using it. Webhooks are equally worthless in accomplishing what is needed, as nothing seems to fire off a job in Jenkins, regardless of how it is configured.
For starters, are there any references or docs that explain what the following status checks are that are automatically created by Jenkins:
continuous-integration/jenkins/branch
continuous-integration/jenkins/pr-head
continuous-integration/jenkins/pr-merge
Apparently there is no way to delete or edit these ... they just "appear" courtesy of Jenkins. I've seen some discussions, but some explanations contradict one another, so they may just be outdated, inaccurate, etc. I want to know "what does what" so I know which should be 'required' as part of the PR status check.
Any pointers would be appreciated!
I agree, this problem is tricky because Jenkins and its plugins have changed so much throughout the years. Let me tell you how I accomplished what you're asking for. I will post all of my version numbers (mostly up to date).
Jenkins Version: 2.176.1 (java -jar /usr/share/jenkins/jenkins.war --version)
Plugins
github 1.29.4
github-api 1.9
github-branch-source 2.5.3
github-pullrequest 0.2.5
pipeline-github-lib 1.0
Also, I use the Blue Ocean interface, which might affect things (who knows)
blueocean 1.17.0
blueocean-git-pipeline 1.17.0
blueocean-github-pipeline 1.17.0
Github Webhooks
First off, set up webhooks for your system. This is a good guide for Github Webhooks
Go to your Github repository and click on the Settings tab. Then select 'Webhooks' in the left menu:
The URL of my Jenkins setup is https://jenkinsci.dorian.com. So, in the 'Payload URL' box, I put https://jenkinsci.dorian.com/github-webhook/
I left the settings as "application/json" and "send me everything" and "active"
The Webhooks area has a handy 'Recent Deliveries' section which can show you if your webhooks are making it to Jenkins. At first, I had the wrong URL so mine has red Xs next to them. Now, they're all green checkmarks.
Github Access Token
Many guides suggest that you provide Jenkins with a personal access token to communicate with your repo. To do that, go to your account avatar in the top right and select Settings -> Developer Settings -> Personal access tokens->Generate Token
Put whatever you want for the description. Under 'select scopes', if you just want it to work, select every checkbox in the list.
I selected:
repo:status
write:repo_hook
read:repo_hook
admin:org_hook
Click save and you'll be shown your secret key. Copy this somewhere safe (we'll use it soon).
Configuring Jenkins
Now for the hard part. Try and install all of the plugins I've listed above.
Go to Jenkins-Manage Jenkins->Configure System
Locate the Github section and click Add Github Server
Name: Github
Api URL: https://api.github.com
Manage Hooks: true
Under credentials, click "Add." You'll be brought to a menu. Select "Secret Text"
Scope: Global
Secret: paste your access token from earlier
ID: (I left this blank)
Description: DorianGithubCreds
Hit save. Then, select DorianGithubCreds from the credentials list.
To test, hit "Test Connection." Mine returns 'Credentials verified for user dnrahamim', rate limit: 4998
Now go down to Github Pull Request Builder
GitHub Server API URL: https://api.github.com
Jenkins URL override: (blank)
Shared Secret: (blank)
Credentials: DorianGithubCreds
Auto-manage webhooks: true
Everything else is blank
Configure Job
Go to the job that should be building your repo
Select 'Configure' in the left menu
Under Projects->Github Organization
Credentials: DorianGithubCreds
Owner: Dorian
Behaviors:
Discover branches
Strategy: Exclude branches that are also filed as PRs
Discover pull requests from origin
Strategy: Merging the pull request with the current target branch revision
Discover pull requests from forks
Strategy: Merging the pull request with the current target branch revision
Trust: From users with Admin or Write permission
Project Recognizers
Pipeline Jenkinsfile
Path: Jenkinsfile (my Jenkinsfile is in the project root)
Build Strategies: (intentionally blank)
Notifications
Now, when I do a pull request, or whenever I post a change to a pull request, Jenkins run a fresh build for that branch.
The Pull Request itself in Github also lists its "Status Checks" at the bottom. When the build is pending, the status check is yellow. If it succeeds it gets a green checkmark. If it fails, it gets a red X.
I initially had a problem because I had an old Jenkins box which was also configured to manage Github webhooks and build pull requests. Its builds were failing so its notifications were the ones getting through to my pull request. I fixed that problem by preventing that old Jenkins box from building my newest branches. Once the old Jenkins box stopped building, the notifications from the new Jenkins box made it through to Github.
Wrapping up
That's it! That's everything I intentionally configured. Please try out my configuration and see if it works for you. Let me know if I left anything out.
The hard part with configuring Jenkins with Github is that, although there are many guides, the suggestions often conflict with each other and very many are out of date (sometimes even official documentation is out of date).
Nonetheless, here are some Resources:
This is a good guide for Github Webhooks
Github's Whitepaper on CI with Jenkins (It doesn't explain much in detail but it gives a good overview)
Github pull request builder plugin
Semi-official SO post for showing build status on Github repo
GitHub has "add webhook" feature which is accessible in the repository settings --> Webhooks section. This has 4 inputs
1. Payload URl - Enter the Jenkins url
2. Content Type - application/json
3. Secret - this is optional if you want to configure secret
4. Which events would you like to trigger this webhook? - select the option "Let me select individual events"
Bunch of checkbox options are visible, check "Pull requests" option. This option will send a request to Jenkins when Pull request is opened
Next step is create a job in Jenkins which will listen to GitHub events and kick off the build
Is there a way to trigger Travis CI build for repository X each time there's a push to repository Y? Specifically, I want my builds to start each time there's a push to http://github.com/tensorflow/tensorflow
Good question! Here are some solutions that I could think of:
If you have admin privileges on the repo (or know someone who does), you could create a webhook that subscribes to the push event and when triggered, start a build on Travis CI using the Travis API.
This would entail:
Creating a new GitHub webhook over on http://github.com/tensorflow/tensorflow/settings/hooks/new. While of course, customizing the settings as you see fit, but with the information I have, I recommend using the application/json content type and only have GitHub trigger the webhook with the push event.
Write a small web app expecting the HTTP POST payloads from GitHub and start builds using Travis CI's API. This web app can be written in any language but it must be deployed to somewhere that is always awake and listening (to prevent missing builds).
Here's my example of that.
post "/push-webhook" do
uri = URI.parse("https://api.travis-ci.org/repo/your-org/your-repo/requests")
request = Net::HTTP::Get.new(uri.request_uri)
request["Content-Type"] = "application/json"
request["Accept"] = "application/json"
request["Travis-API-Version"] = "3"
request["Authorization"] = "token your-token"
body = { "request" => { "branch" => "master" } }
request.body = body.to_json
response = http.request(request)
end
And voila! Once this web app is deployed, and your GitHub webhook is configured properly, you should see builds to run on Travis CI with every new push on http://github.com/tensorflow/tensorflow.
Helpful documentation
https://docs.travis-ci.com/user/triggering-builds/
https://developer.github.com/webhooks/
https://developer.github.com/webhooks/configuring/
However, if you do not have admin privileges on the repo, you could create a mirror of repository that is in your control and then follow the instructions above (with a few differences). From the little research I did, it's not possible (or at least not easy) to create a mirror of a repository all on GitHub without admin access of the original/official repository.
With that said, I found a workaround that should work.
Import tensorflow/tensorflow to GitLab and use the Mirror Repository feature so it mirrors http://github.com/tensorflow/tensorflow as your GitLab repo's upstream.
From there, follow the instructions above as normal except use GitLab's webhook API instead of GitHub's to send push events to trigger our web app to start builds on Travis CI.
Helpful documentation
https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/
https://docs.gitlab.com/ce/user/project/integrations/webhooks.html
I hope this information was helpful. Please let me know if you have any other questions and I'd be happy to help in any way I can. :)