I'm building out one of my company project through Github actions, in which we are running the workflow from latest pull request raised. I have notice one thing, whenever it tries to execute the secret from main the repository, its gives error as bad credentials.
Same stage when I tried to run from main repository it works fine. Do We have given some permissions to pull request to call secret from main repository.
Any suggestions will help.
By default, pull-request builds don't get access to the secrets to prevent people from using the pull requests to exfiltrate your secrets through a change that reads the environment and sends the data somewhere else.
Due to the dangers inherent to automatic processing of PRs, GitHub’s standard pull_request workflow trigger by default prevents write permissions and secrets access to the target repository. However, in some scenarios such access is needed to properly process the PR. To this end the pull_request_target workflow trigger was introduced.
See here for additional details:
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
Related
I have a problem with running github actions on branches created automatically from within other action. Config file triggers them on push to branches that start with feature-.
Then I have a python script using PyGithub and create_git_ref for branch creation. Everything works fine if I do it from local terminal, branch is created and actions are triggered properly, things change when the same script is launched from within github action using GITHUB_TOKEN as an authorization, then those actions are canceled even before they start, anyone experienced such a problem before? What am I missing?
The GITHUB_TOKEN has a specific scope os permissions, and it doesn't have the one(s) you need here.
Instead, you need to use a Personal Access Token and add it as a secret (for example ACCESS_TOKEN as you can't use the GITHUB_ prefix) and call it in your workflow using ${{ secrets.ACCESS_TOKEN }}.
Using the official guide, created build project to run tests on GitHub PullRequests creation. The webhook is correctly shown on GitHub, builds are being triggered in Codebuild, however, the build status is not shown in Github, despite the option Report build status is set true. If I correctly understood the tutorial, Codebuild has native support of GitHub, and after successful creation of a webhook, the new verification check should be added for PR submission automatically, any suggestions to make this work?
It should work automatically. If builds are triggering but codebuild is not reporting back on the status, then it sounds like the codebuild project no longer has permission to the repo. You could try adding the GitHub source to codebuild again.
"Report build status" actually has no effect when triggered by a webhook, and should always report back in theory (https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html). It's set to false for my project and always updates the pull requests.
Ensure the GitHub user has write access to the repository, and if you're using a Personal Access Token (PAT), ensure the repo:status scope is granted:
Grants read/write access to public and private repository commit statuses. This scope is only necessary to grant other users or services access to private repository commit statuses without granting access to the code.
https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
(I experienced this issue recently. The PAT had the necessary scopes granted but the GitHub user had read-only access to the repository. Granting the GitHub user write permission solved the problem.)
So, I've been using Jenkins for quite a while. I have set up numerous projects with the Github Pull Request Builder plugin to run tests whenever someone opens a pull request, and then trigger some other job (build, push, deploy, etc) whenever the pull request actually gets merged to master.
So, is there any way to set this up with a Jenkinsfile, or the organization folders, or the multibranch build deal?
The github-organization-folder plugin in combination with the multi-branch plugin plugin offers exactly this awesome feature: It scans a whole organization (optionally restricted to certain patterns in repo/branch names) for Jenkinsfiles and automatically adds jobs. This also happens for Pull Requests.
Once the PR is closed, it automatically removes the job.
To avoid arbitrary code execution, an organization member has to trigger building the job (same as for the GPRB plugin). The phrase can be configured in the Jenkins System settings.
EDIT: Under the Advanced section in Jenkins, you find options about what types of PR you want to build. If you build fork PRs, then there's afaik no way to prevent running code without prior inspecting it.
An example, how this looks like:
Basically whenever somebody raises a PR on my repository, I want to ensure that the person raising the PR has performed some actions (running a script etc.)
So is there a way to set up some rule or some alert so as to remind the person to perform that action before raising the PR.
You should use something called integration. Here you can see the GitHub Integrations Directory.
My favorite is Travis CI–you set it up using a .travis.yml file and then after the commits are pushed the tests are run and Travis sends the status response which will be visible to in the Pull request.
However, this can't stop the user to submit the pull request.
Like I mentioned, you cannot stop the user to open pull requests but you can tell him/her the steps how to contribute using the CONTRIBUTING.md in your project. Then when somebody opens a pull request or issue will see this alert:
Currently, my team is using TeamCity to automatically build pull requests from GitHub.
We have a configuration to build all the pull requests. In the version control settings of the config, our branch specification is
+:refs/pull/*/merge
In the "Build Triggers" configuration setting, we have only one trigger with the following trigger rule:
+:root=Pull Requests on our Repository:\***/*\*
"Pull Requests on our Repository" is our VCS root name.
The issues:
When someone views a pull request on GitHub website without doing anything else, a build would be triggered in the TeamCity build agent. This is quite annoying, because from time to time, we have multiple build agents building the same pull requests (when multiple people view it).
When someone comments on a pull request, a build would also be triggered.
From my perspective, the only time I want TeamCity to start a build is when new commits are pushed to the pull requests.
Is there a way to do it?
Github's refs/pull/*/merge branches are updated every time mergeability of the branch is recalculated, i.e. on every commit to destination (most likely master) branch. They are also updated when pull request is closed and then reopened. Github's support says these branches are not intended for end users use. The only workaround at the moment is to run builds on refs/pull/*/head branches automatically and on refs/pull/*/merge branches manually.
Do you have TeamCity configured as per this blog post? I then activate the TeamCity service hook in GitHub which takes care of triggering a build in TeamCity whenever there is a push. This seems to do the right thing for me. Or am I missing something?
I know this is old but I wanted to post what we've found as alternatives:
Stop using VCS roots altogether as a mechanism for triggering pull requests. Instead, configure a GitHub webhook to notify a web app of yours whenever there is an update to a PR and only then trigger a build via the TeamCity REST API.
In your build config, add a step that checks what changed in the PR. If nothing changed (i.e. no new commits were added), or if the PR is closed, cancel the build. The problem with this is that the build queue will still be populated with builds that will then be cancelled. Also, you'd have to store somewhere the last commit that was built in order to do the check.
According to their TeamCity's issue tracker, the issue of the TeamCity.GitHub plugin causing an infinite loop of builds was fixed in v9.0