I was reviewing a pull request in our Azure DevOps instance and I noticed that in the Files tab some lines of code were annotated with flags, checkmarks and exclamation marks (see screenshot). I wasn't able to figure out what they mean. Hovering over them didn't display a hint balloon. Does anyone know?
Once you have configured a pipeline that collects and publishes code coverage, it posts a code coverage status when a pull request is raised. By default, the server checks for atleast 70% of changed lines being covered by tests.
In the changed files view of a pull request, lines that are changed are also annotated with coverage indicators to show whether those lines are covered. Check Code coverage for pull requests for details.
Related
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 am currently attempting to build a small program, that, using the Github API would make a small change to a file in a repository, add a tag to the commit that change belongs to, then points the HEAD of the branch to said commit, which would then trigger Actions, after the entire operation has completed. I noticed, however, that when I tested my code, the commit would show up, but there would not be a tag visible anywhere. I made note of the fact that the API was, in fact, receiving the request to set the tag, and there it seems to have gone through, but not on the repo itself it seems.
For reference, I was following this tutorial, and then adding this call after step 4.
Any help would be very much appreciated!
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.
We have had two stories moved from "In Progress" to "Done" status by Azure Boards automatically. From what I can tell we don't have any rules set for it and can't seem to find out why the system is automatically moving stories. Any suggestions or help would be appreciated, I am afraid we are going to miss items that actually need to be worked.
If the story on the Azure DevOps board is linked to some code branch or pull request in the code repository, changes to the repository can update the status of the story. For example, if you link the story to some Pull Request* (as stated by #Daniel Mann), and then you complete that Pull Request, the story will automatically be moved to "Done" state.
You can check the Development and Related Work sections of the story (usually on the right) to see if it has some link to the code.
I have set up Jenkins to use the GitHub pull request builder. It's working great! Except one little thing. My test suite creates HTML Reports (which I have beautifully posted using the HTML result poster plugin) but I can't seem to change the status message that gets posted to GitHub. My commits all get marked like:
The status of the commit gets updated properly, but the message part always says "Build finished. No test results found."
I can't seem to figure out how to change this message based on the status of the test suite. So, basically the only feedback I'm getting is the exit status of my shell script. This script does all of the building, testing, and handling of results, etc. This is reasonably acceptable in the event of a pass, but in the event of a failure, this message could be much more helpful! Even just knowing whether it was a build failure vs. a test suite failure would be nice, so then I can adequately verbally abuse the person who made the pull request :).
Everything else is working so good, that I can't figure out what seems like a trivial change is driving me crazy! Any ideas?
FWIW, the logic was added here: https://github.com/janinko/ghprb/commit/ffbc581d2712d6b99b9c6d0b081d7895a5ee8039
I believe you just need to generate JUnit formatted test output, and you may or may not need to ad a post-build step to publish the JUnit XML output.