Currently this check is run on every push to stable branches which all
fail since they fail to fetch the non-existent .github/path-rules.txt
from the just-updated branches.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60709
Add myself formally as the "maintainer" for atf, kyua, and lutok, both
in the GitHub CODEOWNERS and MAINTAINERS files.
This change matches the herald rules I recently setup for these
third-party components.
I have been the de-facto maintainer for a few years now.
Also mention the #scheduler group for reviews on Phabricator.
Sponsored by: The FreeBSD Foundation
I've been the quasi-defacto component maintainer for OpenSSL since
14.0-RELEASE. Make it official via CODEOWNERS/MAINTAINERS.
The goal is to help guide those interested in making changes in this
space to solicit my input with the new vendor import process and
coordinate fixes with upstream until things are at a point where most of
this is automated a system of automated checks and balances to confirm
that the updates being made to the component help maintain a security
supply chain for this given component.
Thank you benl and jkim for your past efforts in this component area.
Hopefully I can do my part to help improve this critical space further
as you both did in your respective tenures.
MFC after: 3 days
If this eventually poses a problem for unsupported branches we can fix
them directly.
Sponsored by: Innovate UK
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D53838
Google developed the Capsicum unit test suite[1] as part of the
Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD
and unit tests developed as part of the initial Capsicum-Linux port.
Capsicum-Linux was archived as of October 31, 2022 and is no longer
being maintained. FreeBSD is currently the only consumer of and
contributor to the test suite. Move the src into tests/sys/capsicum to
simplify ongoing maintenance.
The makefiles were deleted as we (continue to) use the existing bespoke
FreeBSD Makefile, and CONTRIBUTING.md was removed as the Google CLA is
no longer applicable.
[1] https://github.com/google/capsicum-test
[2] https://github.com/google/capsicum-linux
Reviewed by: asomers, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54917
If you tag me on manual reviews, I will help you. I'm very intersted in
helping keep things standard and predictable across the manual. As these
files say, this is not intended to imply any desire for blocking.
MFC after: 3 days
Add code to fetch and decode CODEOWNERS and automatically @ people in
the review.
Create a new file, .github/path-rules.txt that has a set of paths to
match and specific warnings about that part of the tree. We'll use this
to try to wave off pull requests in certain areas of the tree, as well
as remind people when contrib is involved, etc.
Sponsored by: Netflix
So as a proof of concept, sync the info we have with the #bhyve
phabricator group. This is imperfect, but will help test out providing
better feedback to diff submitters.
Sponsored by: Netflix
Yea, I realize these are decaying, but I'm going to take a run at
automatically tagging reviews for github pull requests. I suspect that
tagging will help with the 'stale' issues with at least CODEOWNER. As
better data becomes available, especailly for contrib, I'll update
things.
Sponsored by: Netflix
Rather than superscript <sup>, for a nicer looking list.
Reviewed by: vexeduxr
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53000
Make it easy for contributors to find the referenced information.
Reviewed by: ziaee
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51346
Be explicit that the user should update their branch and re-push to
update the pull request.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51332
Workflows triggered by the 'pull_request' event can't have write
permissions. With write permissions a malicious pull request can alter
or create a workflow that either leaks the GITHUB_TOKEN with the write
permissions or do malicious things in the workflow itself.
The 'pull_request_target' event on the other hand allows workflows to
run with write permissions but runs on the merge base of the PR, this
way a pull request that alters such a workflow will not have it's code
run until it's merged.
Signed-off-by: Ahmad Khalifa <[email protected]>
Reviewed by: imp, emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/1581
Add a new 'checklist' workflow that checks the commit messages on pull
requests. Currently, the workflow creates a comment on the pull request
if any of these conditions are hit:
- Missing Signed-off-by
- Malformed Signed-off-by
- Bad email (i.e *noreply*)
Reviewed by: emaste, imp
Pull request: https://github.com/freebsd/freebsd-src/pull/1570
Signed-off-by: Ahmad Khalifa <[email protected]>
Only fetch the commits we need instead of fetching the entire history.
Unfortunately there doesn't seem to be a way to add 1 to the number of
commits without an extra step, so do it in a new step and pass the
information onto $GITHUB_ENV so it can be used later.
Signed-off-by: Ahmad Khalifa <[email protected]>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1538
Ubuntu 24.04 is the most recent LTS release. Use it and the previous
22.04 LTS for cross build testing.
Reported by: emaste, jhb
Sponsored by: Arm Ltd
Pull Request: https://github.com/freebsd/freebsd-src/pull/1399
Jim Harris no longer has a commit bit and has moved on from being the
FreeBSD nvme driver maintainer at Intel. I've been reviewing things
so I'll take that up.
Sponsored by: Netflix
John Baldwin