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.
Related
I just started working on a project that was created with Nuxt and a CI pipeline using Cirlce CI that detects changes in the repository and upload files via SFTP to DreamHost.
We also have a netlify cms setup that sends .md files to the repository that are read and displayed on the page.
Now to the weird part.
Whenever I change something in the repository (push from my local repo, or use the cms) the changes appear on the site as they should. They correctly trigger a rebuild within circle.ci, which completes successfully and when I look at the live site they are present.
However when checking back a couple hours later they have dissapeared. The changes are still present in the github repository, but they are inconsistent with the state of the live page which has reverted to its previous state.
I can manually trigger rebuilds within circle.ci but the same thing occurs, i can see the changes for some time, then they dissapear.
I don't even know where to start looking for the problemect.
Any leads, or well aimed shots in the dark would be greatly appreciated, many thanks!
Edit.
I think this might be relevant: Every 12 hours we trigger a rebuild on the page, mostly to check for outdated content and deliver freshly rendered pages. When i checked the site index under the _nuxt pages, i see the following:
There are older versions of the scripts that are correct and new versions that are incorrect, those new versions are then referenced, resulting in the content being false.
Why are the automatic rebuilds 'overwriting' the old build?
Where can i find out more about those triggers?
OP's issue was mainly coming from the fact that the app was pulling from the wrong branch.
Fixing that one, did it.
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.
I am not by any means a sophisticated github user. I have learned the minimum handful of commands needed to add, commit, and push my project code to the public github.com repository. So far it's been working fairly well... until today when I tried to create a new release (my third).
For some reason, when I try to publish my new release, I get the message
Tag could not be created. Pre-receive hooks failed.
I have never seen this message before.
I have tried various different tag names; I have tried logging out and back in again; I have tried pre-tagging on my local disk copy of the repo; I have pushed and pulled (both ends are up to date). This about exhausts my repertoire of things to try :-(
As a relative n00b I find this message incredibly opaque (sigh). I have tried googling for it, but quickly got in over my head -- most of the hits I found were discussions about people setting up their own networked repos and installing or tweaking their own custom "pre-receive hooks", whereas I am just a dumb user of github.com apparently struggling with whatever "pre-receive hooks" they have installed (?). If anyone can at least point me in the right direction I'd be most grateful.
Make sure you select the tag version in the dropdown. The GitHub form will let you submit when this field is blank, but it will always display the mentioned error message. (You do not need a 'v' prefix.).
The latest Github form makes this more cryptic by having a dropdown titled 'Tag:Choose or Create" that hides the fact that this field is both required but not set.
Latest Github Form
Older Github Form
In a GitHub context, I have seen that error message in this issue
It could be a tag naming convention issue.
The GitHub release documentation recommends (enforces?) a tag following the semantic versioning naming scheme: vX.Y.Z.
As shown here, try vx.y.z.
Is it possible to create new branch directly from Issue which is posted on Github? We have project hosted on Github with many issues, it would be easy for us just to click one button in Issue web interface and create new branch for it to start developing.
This is not possible directly from the issue interface. I can try to provide you some workarounds and maybe start a debate why one would want this feature:
Creating branches directly on the web interface
After you've noticed that you need to start working on an issue you can just go to the repository main page (keyboard shortcut gc) and create a branch with the name you want:
Chrome extensions
If this is a must for you, you can create a chrome extension that augments the UI and creates a branch directly from the Issues WebUI using the GitHub API. There's a lot of open source extensions that augment the default WebUI.
Is it the most efficient way to start a new feature?
I think this changes from developer to developer, but having worked with GitHub for 7 years using Issues I've never felt the need for this feature because unless it's a one line change that doesn't require local testing or compilation, I still want to get down to my command line and IDE. If I have to do that, I still have to at least git fetch to get the branch I just created directly through the issue interface. If that's the case I've always preferred to just look at the issue and run git checkout -b branch-name, optionally with git push if my team needs to see the branch.
Then the issue name wouldn't normally translate to a branch name, at least I wouldn't want that. So that option to create a branch from an issue would probably need to spin out a prompt to allow me to name the branch what I wanted.
This is just my personal opinion and nothing else, hope it helps :)
GitHub finally added this feature request to their roadmap.
Summary
The branch is the first thing a developer creates when the start
working on a new issue. Creating that association makes it really easy
for someone to then follow the work happening and keep everything
connected as they take their idea to code.
Intended Outcome
We want to help developers get started on work faster and signal to
their team where to find the code changes related to an issue. It
should also be really easy to then follow development to the pull
request without the user needing to do additional work to link
everything together.
How will it work?
From the issue page, a user can quickly create a branch with an
auto-generated or custom name that becomes associated with the issue.
They can then fetch the branch and switch to it in their development
environment and further development changes (such as commits and pull
requests) are automatically associated with the issue.
https://github.com/isaacs/github/issues/1125
Nope. You can subscribe this issue.
You could accomplish this by creating a small script.
I'd start by leveraging the Issues Event webhook. This will fire a JSON payload every time an issue is opened. When the webhook fires, your script can then create a new branch using the Create a Reference API endpoint. Note: URL must be formatted as heads/branch, not just branch.
There is an app that automatically creates branches for issues. You can install it here for free: https://github.com/marketplace/actions/create-issue-branch
If you want to create the branches manually instead of automatically:
It does not enable you (directly) to click on create branch from the issue. Instead you would have to write a comment in the issue consisting of: /cib. If you do that, it automatically creates the branch from the issue.
Please note I have no affiliation with the app.
Recently I saw that Github finally added this feature to its Issues Panel.
All you have to do is navigate to an Issue on Github and scroll down to the following section:
I'm using Travis-CI with GitHub.
I would like to know if is possible to reset the build number and/or delete the related Travis page.
I tried to delete my repo on GitHub but this is not affecting the related Travis page.
Even if I create a new repo, with the same name of the previous, the build number starts from the previous one, and the builds are linking on 404 on GitHub. I know that isn't a big issue, but I would like to keep consistent all my solution.
Unfortunately we don't have a way to delete repositories or builds. If any private data has been exposed, you can always email us to have the logs stripped.
We are working on a way to archive repositories, which basically means that they'll be hidden until a new build is run, see the issue for more information on that.