It would be ideal to refresh github-code-scanning alerts when a branch pr is changed, removing old alerts when they become outdated and avoiding duplicating new alerts.
Following the behavior:
When a new commit is added: Run on this new commit
When a force push occurs: Re-run (deleting old alerts) on all commits which changed (or more simply, deleting all alerts and re-running on the entire branch).
Specifically I have a repository with code scanning and some generic PR (https://github.com/JonathanWoollett-Light/testing-git-hooks/pull/1) here given my force push my desired behavior would have been for it to delete the first alert or not generate the second duplicate alert.
Is this possible? Where should I begin looking to accomplish this?
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 have enabled a couple of different code scanning tools in my GitHub Actions workflow that each upload their results to the GitHub Security tab (via upload-sarif).
One of these scans produces a lot of alerts that are not relevant for my project, as it scans the built container image and produces alerts for all of the packages and utilities included in the base (Linux) image regardless of whether they are used by my application. So I have reviewed all of the alerts on the GitHub Security tab and dismissed (as "Won't Fix") the alerts that are not relevant.
Subsequent executions of the GitHub Actions workflow on the default branch work fine - the code scanning tool still generates all of the alerts, but GitHub sees that the alerts have already been dismissed and doesn't add or re-open them on the Security tab.
However, I also want to run the scan on PRs targeting my default branch in order to catch any new alerts before they are merged. But here GitHub doesn't appear to be checking that the alerts have already been dismissed on the default branch, so the code scanning check fails on every PR. Worse, if I ignore the check and merge the PR anyway, the alerts are transferred over to the default branch and need to be manually dismissed again.
Is there a workaround for this, or should I be approaching this in a different way?
I have discovered that the code scanning tool in question (Trivy) does not include fingerprints in its SARIF output, which is what confuses GitHub. I've made a feature request for Trivy here: https://github.com/aquasecurity/trivy/issues/1840
As a workaround, I've discovered that keeping the container image name static for code scanning allows GitHub's fallback deduplication logic to correctly identify duplicate alerts.
I'm pretty sure this setup was working at one point for us. I changed our builds a bit to reflect some operational changes and now the CI git branch trigger isn't working. I'm trying to get it so when a PR is merged into master it triggers the release build. I can trigger this build manually but not when submitting a PR to master from dev and then accepting the PR (on github).
Is anyone else having issues or know whats wrong?
Adding an answer so this more visible. #starain-MSFT comment was the solution.
I added a new build with the same trigger and it fixed the other one not getting triggered. Then deleted the new build I had added and everything is working.
Cloning my build definition didn't work, unfortunately, and neither did saving a trivial change to the build definition. Instead, I had to explicitly disable the CI trigger, save, then re-enable it and save it again. (Annoying, because I had to redefine all the rules.) But give it a try if the accepted answer doesn't do it for you.
I also wonder if adding a random branch to the triggering branches list, saving, then removing the random branch and saving again would work (and save you from having to redefine everything).
I am using the git plugin for eclipse and I have noticed a problem with it and hoping this is a simple configuration change. Can anyone help?
When switching branches, the uncommitted changes are being merged across onto the newly checked out branch (only in certain circumstances). It seems as if this happens every time when it is "safe" to do so. The way to recreate is:
Create feature branch "branch1" from remote repository
Create feature branch "branch2" from same remote repository
Make changes on "branch2" and don't commit changes.
Switch to "branch1"
a. No confirmation message is shown.
b. The uncommitted changes from "branch2" are merged onto "branch1"
I want to be able to force the commit message to appear (just like it does using git-bash). Is this possible?
To my understanding, this behavior is intended by EGit: a checkout is performed as long as the files to be checked out do not collide with the working directory. And uncommitted changes are left as they are.
If you think EGit should offer a different strategy of handling uncommitted changes I suggest to open an enhancement request: https://eclipse.org/egit/support/
In the meanwhile, you may want to (manually) stash uncommitted changes prior to switching branches. That's what I see most people do in this situation.
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