mirror of
https://github.com/vortexgpgpu/vortex.git
synced 2025-04-24 05:47:35 -04:00
adding documemtation for contributing and documentation
This commit is contained in:
parent
43154cf738
commit
b20320236d
3 changed files with 73 additions and 5 deletions
36
docs/continuous_integration.md
Normal file
36
docs/continuous_integration.md
Normal file
|
@ -0,0 +1,36 @@
|
|||
# Continuous Integration
|
||||
- Each time you push to the repo, the Continuous Integration pipeline will run
|
||||
- This pipeline consists of creating the correct development environment, building your code, and running all tests
|
||||
- This is an extensive pipeline so it might take some time to complete
|
||||
|
||||
|
||||
## Protecting Master Branch
|
||||
Navigate to your Repository:
|
||||
Open your repository on GitHub.
|
||||
|
||||
Click on "Settings":
|
||||
In the upper-right corner of your repository page, click on the "Settings" tab.
|
||||
|
||||
Select "Branches" in the left sidebar:
|
||||
On the left sidebar, look for the "Branches" option and click on it.
|
||||
|
||||
Choose the Branch:
|
||||
Under "Branch protection rules," select the branch you want to protect. In this case, choose the main branch.
|
||||
|
||||
Enable Branch Protection:``
|
||||
Check the box that says "Protect this branch."
|
||||
|
||||
Configure Protection Settings:
|
||||
You can configure various protection settings. Some common settings include:
|
||||
|
||||
Require pull request reviews before merging: This ensures that changes are reviewed before being merged.
|
||||
Require status checks to pass before merging: This ensures that automated tests and checks are passing.
|
||||
Require signed commits: This enforces that commits are signed with a verified signature.
|
||||
Restrict Who Can Push:
|
||||
You can further restrict who can push directly to the branch. You might want to limit this privilege to specific people or teams.
|
||||
|
||||
Save Changes:
|
||||
Once you've configured the protection settings, scroll down and click on the "Save changes" button.
|
||||
|
||||
Now, your main branch is protected, and certain criteria must be met before changes can be pushed directly to it. Contributors will need to create pull requests, have their changes reviewed, and meet other specified criteria before the changes can be merged into the main branch.
|
||||
|
18
docs/contributing.md
Normal file
18
docs/contributing.md
Normal file
|
@ -0,0 +1,18 @@
|
|||
# Contributing to Vortex on Github
|
||||
|
||||
## Github Details
|
||||
- There are two main repos, `vortex` (public, this one) and `vortex-dev` (private)
|
||||
- todo: Most current development is on `vortex`
|
||||
- If you have a legacy version of `vortex`, you can use the releases branch or tags to access the repo at that point in time
|
||||
|
||||
## Contribution Process
|
||||
- You should create a new branch from develop that is clearly named with the feature that you want to add
|
||||
- Avoid pushing directly to the `master` branch instead you will need to make a Pull Request (PR)
|
||||
- There should be protections in place that prevent pushing directly to the main branch, but don't rely on it
|
||||
- When you make a PR it will be tested against the continuous integration (ci) pipeline (see `continuous_integration.md`)
|
||||
- It is not sufficient to just write some tests, they need to be incorporated into the ci pipeline to make sure they are run
|
||||
- During a PR, you might receive feedback regarding your changes and you might need to make further commits to your branch
|
||||
|
||||
|
||||
## Creating and Adding Tests
|
||||
see `testing.md`
|
|
@ -2,18 +2,18 @@
|
|||
|
||||
## Running a Vortex application
|
||||
|
||||
The framework provides a utility script: blakcbox.sh under the /ci/ folder for executing applications in the tests tree.
|
||||
The framework provides a utility script: blackbox.sh under the /ci/ folder for executing applications in the tests tree.
|
||||
You can query the commandline options of the tool using:
|
||||
|
||||
$ ./ci/blakcbox.sh --help
|
||||
$ ./ci/blackbox.sh --help
|
||||
|
||||
To execute sgemm test program on the simx driver and passing "-n10" as argument to sgemm:
|
||||
|
||||
$ ./ci/blakcbox.sh --driver=simx --app=sgemm --args="-n10"
|
||||
$ ./ci/blackbox.sh --driver=simx --app=sgemm --args="-n10"
|
||||
|
||||
You can execute the same application of a GPU architecture with 2 cores:
|
||||
|
||||
$ ./ci/blakcbox.sh --core=2 --driver=simx --app=sgemm --args="-n10"
|
||||
$ ./ci/blackbox.sh --core=2 --driver=simx --app=sgemm --args="-n10"
|
||||
|
||||
When excuting, Blackbox needs to recompile the driver if the desired architecture changes.
|
||||
It tracks the latest configuration in a file under the current directory blackbox.<driver>.cache.
|
||||
|
@ -30,4 +30,18 @@ You can execute the default regression suite by running the following commands a
|
|||
You can execute the default opncl suite by running the following commands at the root folder.
|
||||
|
||||
$ make -C tests/opencl run-simx
|
||||
$ make -C tests/opencl run-rtlsim
|
||||
$ make -C tests/opencl run-rtlsim
|
||||
|
||||
## Creating Your Own Regression Tests
|
||||
- Inside `test/` you will find a series of folders which are named based on what they test
|
||||
- You can view the tests to see which ones have tests similar to what you are trying to create new tests for
|
||||
- once you have found a similar baseline, you can copy the folder and rename it to what you are planning to test
|
||||
- `testcases.h` contains each of the test case templates
|
||||
- `main.cpp` contains the implementation of each of the test cases and builds a test suite of all the tests cases you want
|
||||
|
||||
Compile the test case: `make -C tests/regression/<testcase-name>/ clean-all && make -C tests/regression/<testcase-name>/`
|
||||
|
||||
Run the test case: `./ci/blackbox.sh --driver=simx --cores=4 --app=<testcase-name> --debug`
|
||||
|
||||
## Adding Your Tests to the CI Pipeline
|
||||
see `continuous_integration.md`
|
Loading…
Add table
Add a link
Reference in a new issue