Run pre-commit's whitespace related hooks on projects/rocm-core (#2127)
In order for pre-commit to be useful, everything needs to meet a common baseline. Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tento commit je obsažen v:
Mario Limonciello
GitHub
+21
-21
@@ -1,26 +1,26 @@
|
||||
name: ROCm CI Caller
|
||||
on:
|
||||
on:
|
||||
# Commenting below to avoid re-runs of amd smi for trivial rebases
|
||||
pull_request:
|
||||
branches: [release/rocm-rel-*, amd-mainline]
|
||||
types: [opened, reopened, synchronize]
|
||||
push:
|
||||
branches: [amd-mainline]
|
||||
workflow_dispatch:
|
||||
issue_comment:
|
||||
pull_request:
|
||||
branches: [release/rocm-rel-*, amd-mainline]
|
||||
types: [opened, reopened, synchronize]
|
||||
push:
|
||||
branches: [amd-mainline]
|
||||
workflow_dispatch:
|
||||
issue_comment:
|
||||
types: [created]
|
||||
|
||||
jobs:
|
||||
call-workflow:
|
||||
if: github.event_name != 'issue_comment' ||(github.event_name == 'issue_comment' && github.event.issue.pull_request && (startsWith(github.event.comment.body, '!verify') || startsWith(github.event.comment.body, '!verify release') || startsWith(github.event.comment.body, '!verify retest')))
|
||||
|
||||
jobs:
|
||||
call-workflow:
|
||||
if: github.event_name != 'issue_comment' ||(github.event_name == 'issue_comment' && github.event.issue.pull_request && (startsWith(github.event.comment.body, '!verify') || startsWith(github.event.comment.body, '!verify release') || startsWith(github.event.comment.body, '!verify retest')))
|
||||
uses: AMD-ROCm-Internal/rocm_ci_infra/.github/workflows/rocm_ci.yml@mainline
|
||||
secrets: inherit
|
||||
with:
|
||||
input_sha: ${{github.event_name == 'pull_request' && github.event.pull_request.head.sha || (github.event_name == 'push' && github.sha) || (github.event_name == 'issue_comment' && github.event.issue.pull_request.head.sha) || github.sha}}
|
||||
input_pr_num: ${{github.event_name == 'pull_request' && github.event.pull_request.number || (github.event_name == 'issue_comment' && github.event.issue.number) || 0}}
|
||||
input_pr_url: ${{github.event_name == 'pull_request' && github.event.pull_request.html_url || (github.event_name == 'issue_comment' && github.event.issue.pull_request.html_url) || ''}}
|
||||
input_pr_title: ${{github.event_name == 'pull_request' && github.event.pull_request.title || (github.event_name == 'issue_comment' && github.event.issue.pull_request.title) || ''}}
|
||||
repository_name: ${{ github.repository }}
|
||||
base_ref: ${{github.event_name == 'pull_request' && github.event.pull_request.base.ref || (github.event_name == 'issue_comment' && github.event.issue.pull_request.base.ref) || github.ref}}
|
||||
trigger_event_type: ${{ github.event_name }}
|
||||
secrets: inherit
|
||||
with:
|
||||
input_sha: ${{github.event_name == 'pull_request' && github.event.pull_request.head.sha || (github.event_name == 'push' && github.sha) || (github.event_name == 'issue_comment' && github.event.issue.pull_request.head.sha) || github.sha}}
|
||||
input_pr_num: ${{github.event_name == 'pull_request' && github.event.pull_request.number || (github.event_name == 'issue_comment' && github.event.issue.number) || 0}}
|
||||
input_pr_url: ${{github.event_name == 'pull_request' && github.event.pull_request.html_url || (github.event_name == 'issue_comment' && github.event.issue.pull_request.html_url) || ''}}
|
||||
input_pr_title: ${{github.event_name == 'pull_request' && github.event.pull_request.title || (github.event_name == 'issue_comment' && github.event.issue.pull_request.title) || ''}}
|
||||
repository_name: ${{ github.repository }}
|
||||
base_ref: ${{github.event_name == 'pull_request' && github.event.pull_request.base.ref || (github.event_name == 'issue_comment' && github.event.issue.pull_request.base.ref) || github.ref}}
|
||||
trigger_event_type: ${{ github.event_name }}
|
||||
comment_text: ${{ github.event_name == 'issue_comment' && github.event.comment.body || '' }}
|
||||
|
||||
@@ -321,7 +321,7 @@ set ( CPACK_RPM_CORE_STATIC_POST_UNINSTALL_SCRIPT_FILE "${BUILD_DIR}/prerm" )
|
||||
set ( CPACK_RPM_PACKAGE_DESCRIPTION "${EXTENDED_PACKAGE_DESCRIPTION}" )
|
||||
|
||||
if ( DEFINED CPACK_PACKAGING_INSTALL_PREFIX )
|
||||
set ( CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
|
||||
set ( CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION
|
||||
"${CPACK_PACKAGING_INSTALL_PREFIX} ${CPACK_PACKAGING_INSTALL_PREFIX}/.info" )
|
||||
endif()
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ROCM-CORE Contributing Guide
|
||||
To ensure the quality of the ROCM-CORE code base, the ROCM-CORE team has
|
||||
established a code review process to inform developers of the steps
|
||||
To ensure the quality of the ROCM-CORE code base, the ROCM-CORE team has
|
||||
established a code review process to inform developers of the steps
|
||||
that are required to shepherd a change-set into the repository.
|
||||
|
||||
#### Table Of Contents
|
||||
@@ -19,14 +19,14 @@ that are required to shepherd a change-set into the repository.
|
||||
|
||||
[References](#References)
|
||||
## How to get started
|
||||
rocm-core is a utility which can be used to get ROCm release version.
|
||||
rocm-core is a utility which can be used to get ROCm release version.
|
||||
It also provides the Lmod modules files for the ROCm release.
|
||||
getROCmVersion function provides the ROCm version.
|
||||
getROCmVersion function provides the ROCm version.
|
||||
|
||||
## How do I contribute
|
||||
### Deliverables
|
||||
All contributions you make will be under the [MIT Software License](copyright).
|
||||
For each new file in repository,
|
||||
For each new file in repository,
|
||||
Please include the licensing header
|
||||
```
|
||||
/*******************************************************************************
|
||||
@@ -64,7 +64,7 @@ All the code is formatted using `clang-format`. To format a file, use:
|
||||
clang-format-10 -style=file -i <path-to-source-file>
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Reporting Issues
|
||||
We use [GitHub Issues](https://github.com/ROCm/rocm-core/issues) to track public **bugs** and **enhancement requests**.
|
||||
|
||||
@@ -90,26 +90,26 @@ Please follow the template below to report any enhancement requests for ROCM-COR
|
||||
|
||||
The author must set labels (and assigns a milestone) according to his/her own understanding.
|
||||
|
||||
Other contributors can change these values if they disagree. That being said,
|
||||
adding a small comment explaining the motivation is highly recommended.
|
||||
Other contributors can change these values if they disagree. That being said,
|
||||
adding a small comment explaining the motivation is highly recommended.
|
||||
In this way, we keep the process flexible while cultivating mutual understanding.
|
||||
|
||||
[**Note**] Most likely, the labels like "bug", "feature" or "complexity*"
|
||||
would not be changed. However, "value*" or "urgency*" might be from mutual
|
||||
[**Note**] Most likely, the labels like "bug", "feature" or "complexity*"
|
||||
would not be changed. However, "value*" or "urgency*" might be from mutual
|
||||
understanding.
|
||||
### Creating a Pull Request
|
||||
|
||||
No changes are allowed to be directly committed to the develop
|
||||
branch of the ROCM-CORE repository. All authors are required to
|
||||
develop their change sets on a separate branch and then create
|
||||
No changes are allowed to be directly committed to the develop
|
||||
branch of the ROCM-CORE repository. All authors are required to
|
||||
develop their change sets on a separate branch and then create
|
||||
a pull request (PR) to merge their changes into the develop branch.
|
||||
|
||||
Once a PR has been created, a developer must choose two reviewers
|
||||
to review the changes made. The first reviewer should be a
|
||||
technical expert in the portion of the library that the changes
|
||||
are being made in. You can find a list of these experts in
|
||||
[CODEOWNERS](CODEOWNERS) list.
|
||||
The second reviewer should be a peer reviewer. This reviewer
|
||||
Once a PR has been created, a developer must choose two reviewers
|
||||
to review the changes made. The first reviewer should be a
|
||||
technical expert in the portion of the library that the changes
|
||||
are being made in. You can find a list of these experts in
|
||||
[CODEOWNERS](CODEOWNERS) list.
|
||||
The second reviewer should be a peer reviewer. This reviewer
|
||||
can be any other ROCM-CORE developer.
|
||||
|
||||
## Responsibility of the Author
|
||||
@@ -121,38 +121,38 @@ The author of a PR is responsible for:
|
||||
* Report on the impact to performance
|
||||
|
||||
## Responsibility of the Reviewer
|
||||
Each reviewer is responsible for verifying that the changes are
|
||||
clearly written in keeping with the coding styles of the library,
|
||||
are documented in a way that future developers will be able to
|
||||
understand the intent of the added functionality, and will
|
||||
Each reviewer is responsible for verifying that the changes are
|
||||
clearly written in keeping with the coding styles of the library,
|
||||
are documented in a way that future developers will be able to
|
||||
understand the intent of the added functionality, and will
|
||||
maintain or improve the overall quality of the codebase.
|
||||
|
||||
Reviewer's task checklist:
|
||||
1. Has the PR passed?
|
||||
2. Does the PR consist of a well-organized sequence of small commits,
|
||||
2. Does the PR consist of a well-organized sequence of small commits,
|
||||
each of which is designed to make one specific feature or fix ?
|
||||
3. Does the PR only include a reviewable amount of changes? Or it is a
|
||||
consolidation of already reviewed small batches? e.g. break it into smaller
|
||||
3. Does the PR only include a reviewable amount of changes? Or it is a
|
||||
consolidation of already reviewed small batches? e.g. break it into smaller
|
||||
testable and reviewable tasks instead of a huge chunk at once.
|
||||
4. Does the PR have sufficient documentation and easy to read and understand,
|
||||
feasible for test and future maintainence, related docs already in place?
|
||||
4. Does the PR have sufficient documentation and easy to read and understand,
|
||||
feasible for test and future maintainence, related docs already in place?
|
||||
if API or functionality has changed?
|
||||
5. For bugfixes and new features, new regression test created?
|
||||
6. Is every PR associated with a ticket or issue number for tracking purposes?
|
||||
|
||||
## The Review
|
||||
During the review, reviewers will look over the changes and make
|
||||
During the review, reviewers will look over the changes and make
|
||||
suggestions or requests for changes.
|
||||
|
||||
In order to assist the reviewer in prioritizing their efforts,
|
||||
In order to assist the reviewer in prioritizing their efforts,
|
||||
authors can take the following actions:
|
||||
|
||||
* Set the urgency and value labels
|
||||
* Set the milestone where the changes need to be delivered
|
||||
* Describe the testing procedure and post the measured effect of
|
||||
* Describe the testing procedure and post the measured effect of
|
||||
the change
|
||||
* Remind reviewers via email if a PR needs attention
|
||||
* If a PR needs to be reviewed as soon as possible, explain to
|
||||
* If a PR needs to be reviewed as soon as possible, explain to
|
||||
the reviewers why a review may need to take priority
|
||||
|
||||
## References
|
||||
|
||||
@@ -4,13 +4,13 @@ ROCM-CORE is a package which can be used to get ROCm release version, get ROCm i
|
||||
It is also important to note that ROCM-CORE takes the role as a base component on which all of ROCm can depend,
|
||||
to make it easy to remove all of ROCm with a package manager.
|
||||
|
||||
getROCmVersion function provides the ROCm version.
|
||||
getROCmVersion function provides the ROCm version.
|
||||
|
||||
It also provides an example Lmod modules files for the ROCm release.
|
||||
|
||||
Lmod module files can be loaded with the following commands.
|
||||
``` shell
|
||||
module load rocm/x.y or
|
||||
module load rocm/x.y or
|
||||
module load rocm
|
||||
```
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
//Copyright © Advanced Micro Devices, Inc., or its affiliates.
|
||||
|
||||
|
||||
//SPDX-License-Identifier: MIT
|
||||
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ function( configure_debian_pkg PACKAGE_NAME_T COMPONENT_NAME_T PACKAGE_VERSION_T
|
||||
)
|
||||
endif()
|
||||
|
||||
# Install Change Log
|
||||
# Install Change Log
|
||||
find_program ( DEB_GZIP_EXEC gzip )
|
||||
if(EXISTS "${CMAKE_BINARY_DIR}/DEBIAN/changelog.Debian" )
|
||||
execute_process(
|
||||
@@ -228,7 +228,7 @@ function( configure_debian_pkg PACKAGE_NAME_T COMPONENT_NAME_T PACKAGE_VERSION_T
|
||||
endfunction()
|
||||
|
||||
# Set variables for changelog and copyright
|
||||
# For Debian specific Packages
|
||||
# For Debian specific Packages
|
||||
function( set_debian_pkg_cmake_flags DEB_PACKAGE_NAME_T DEB_PACKAGE_VERSION_T DEB_MAINTAINER_NM_T DEB_MAINTAINER_EMAIL_T )
|
||||
# Setting configure flags
|
||||
set( DEB_PACKAGE_NAME "${DEB_PACKAGE_NAME_T}" CACHE STRING "Debian Package Name" )
|
||||
@@ -237,7 +237,7 @@ function( set_debian_pkg_cmake_flags DEB_PACKAGE_NAME_T DEB_PACKAGE_VERSION_T DE
|
||||
set( DEB_MAINTAINER_EMAIL "${DEB_MAINTAINER_EMAIL_T}" CACHE STRING "Debian Package Maintainer Email" )
|
||||
set( DEB_COPYRIGHT_YEAR "2025" CACHE STRING "Debian Package Copyright Year" )
|
||||
set( DEB_LICENSE "MIT" CACHE STRING "Debian Package License Type" )
|
||||
set( DEB_CHANGELOG_INSTALL_FILENM "changelog.Debian.gz" CACHE STRING "Debian Package ChangeLog File Name" )
|
||||
set( DEB_CHANGELOG_INSTALL_FILENM "changelog.Debian.gz" CACHE STRING "Debian Package ChangeLog File Name" )
|
||||
|
||||
if( BUILD_ENABLE_LINTIAN_OVERRIDES )
|
||||
set( DEB_OVERRIDES_INSTALL_FILENM "${DEB_PACKAGE_NAME}" CACHE STRING "Debian Package Lintian Override File Name" )
|
||||
|
||||
Odkázat v novém úkolu
Zablokovat Uživatele