mirror of
https://gitlab.kitware.com/vtk/vtk-m
synced 2024-10-05 01:49:02 +00:00
Update CONTRIBUTING.md to cover gitlab piplines
This commit is contained in:
parent
5bc09b976e
commit
142d151caf
@ -32,14 +32,14 @@ Before you begin, perform initial setup:
|
|||||||
This will prompt for your GitLab user name and configure a remote
|
This will prompt for your GitLab user name and configure a remote
|
||||||
called `gitlab` to refer to it.
|
called `gitlab` to refer to it.
|
||||||
|
|
||||||
5. (Optional but highly recommended.)
|
5. (Optional but highly recommended.)
|
||||||
[Register with the VTK-m dashboard] on Kitware's CDash instance to
|
[Register with the VTK-m dashboard] on Kitware's CDash instance to
|
||||||
better know how your code performs in regression tests. After
|
better know how your code performs in regression tests. After
|
||||||
registering and signing in, click on "All Dashboards" link in the upper
|
registering and signing in, click on "All Dashboards" link in the upper
|
||||||
left corner, scroll down and click "Subscribe to this project" on the
|
left corner, scroll down and click "Subscribe to this project" on the
|
||||||
right of VTK-m.
|
right of VTK-m.
|
||||||
|
|
||||||
6. (Optional but highly recommended.)
|
6. (Optional but highly recommended.)
|
||||||
[Sign up for the VTK-m mailing list] to communicate with other
|
[Sign up for the VTK-m mailing list] to communicate with other
|
||||||
developers and users.
|
developers and users.
|
||||||
|
|
||||||
@ -108,6 +108,9 @@ idea of the feature or fix to be developed given just the branch name.
|
|||||||
This is required as VTK-m uses Git-LFS to efficiently support data
|
This is required as VTK-m uses Git-LFS to efficiently support data
|
||||||
files.
|
files.
|
||||||
|
|
||||||
|
4. If you are adding a new feature or making sigificant changes to API,
|
||||||
|
make sure to add a entry to `docs/changelog`. This allows release
|
||||||
|
notes to properly capture all relevant changes.
|
||||||
|
|
||||||
### Guidelines for Commit Messages ###
|
### Guidelines for Commit Messages ###
|
||||||
|
|
||||||
@ -203,7 +206,7 @@ will be filled out for you.
|
|||||||
|
|
||||||
5. In the "**Description**" field provide a high-level description of the
|
5. In the "**Description**" field provide a high-level description of the
|
||||||
change the topic makes and any relevant information about how to try
|
change the topic makes and any relevant information about how to try
|
||||||
it.
|
it.
|
||||||
* Use `@username` syntax to draw attention of specific developers.
|
* Use `@username` syntax to draw attention of specific developers.
|
||||||
This syntax may be used anywhere outside literal text and code
|
This syntax may be used anywhere outside literal text and code
|
||||||
blocks. Or, wait until the [next step](#review-a-merge-request)
|
blocks. Or, wait until the [next step](#review-a-merge-request)
|
||||||
@ -226,6 +229,10 @@ will be filled out for you.
|
|||||||
6. The "**Assign to**", "**Milestone**", and "**Labels**" fields may be
|
6. The "**Assign to**", "**Milestone**", and "**Labels**" fields may be
|
||||||
left blank.
|
left blank.
|
||||||
|
|
||||||
|
7. Enable the "**Allow commits from members who can merge to the target branch.**" option,
|
||||||
|
so that reviewers can modify the merge request. This allows reviewers to change
|
||||||
|
minor style issues without overwhelming the author with change requests.
|
||||||
|
|
||||||
7. Use the "**Submit merge request**" button to create the merge request
|
7. Use the "**Submit merge request**" button to create the merge request
|
||||||
and visit its page.
|
and visit its page.
|
||||||
|
|
||||||
@ -318,32 +325,49 @@ succeeds.
|
|||||||
|
|
||||||
### Testing ###
|
### Testing ###
|
||||||
|
|
||||||
VTK-m has a [buildbot](http://buildbot.net) instance watching for merge
|
Each time a merge request is created or updated automated testing
|
||||||
requests to test. Each time a merge request is updated the buildbot user
|
is automatically triggered, and shows up under the pipeline tab.
|
||||||
(@buildbot) will automatically trigger a new build on all VTK-m buildbot
|
|
||||||
workers. The buildbot user (@buildbot) will respond with a comment linking
|
|
||||||
to the CDash results when it schedules builds.
|
|
||||||
|
|
||||||
The buildbot user (@buildbot) will also respond to any comment with the
|
Developers can track the status of the pipeline for a merge
|
||||||
form:
|
request by using the Pipeline tab on a merge request or by
|
||||||
|
clicking on stage icons as shown below:
|
||||||
|
|
||||||
|
![alt text](docs/build_stage.png "Pipeline")
|
||||||
|
|
||||||
|
When trying to diagnose why a build or tests stage has failed it
|
||||||
|
generally is easier to look at the pruned information reported
|
||||||
|
on [VTK-m's CDash Dashboard](https://open.cdash.org/index.php?project=VTKM).
|
||||||
|
To make it easier to see only the results for a given merge request
|
||||||
|
you can click the `cdash` link under the external stage ( rightmost pipeline stage icon )
|
||||||
|
|
||||||
|
![alt text](docs/external_stage.png "CDash Link")
|
||||||
|
|
||||||
|
In addition to the gitlab pipelines the buildbot user (@buildbot) will respond
|
||||||
|
with a comment linking to the CDash results when it schedules builds.
|
||||||
|
|
||||||
|
The builds for VTK-m that show up as part of the `external` stage of the
|
||||||
|
gitlab pipeline are driven via buildbot, and have a different workflow.
|
||||||
|
When you need to do things such as retry a build, you must issue commands
|
||||||
|
via comments of the following form. The buildbot user (@buildbot) will
|
||||||
|
respond signify that the command has been executed
|
||||||
|
|
||||||
Do: test
|
Do: test
|
||||||
|
|
||||||
The `Do: test` command accepts the following arguments:
|
The `Do: test` command accepts the following arguments:
|
||||||
|
|
||||||
* `--oneshot`
|
* `--oneshot`
|
||||||
only build the *current* hash of the branch; updates will not be
|
only build the *current* hash of the branch; updates will not be
|
||||||
built using this command
|
built using this command
|
||||||
* `--stop`
|
* `--stop`
|
||||||
clear the list of commands for the merge request
|
clear the list of commands for the merge request
|
||||||
* `--superbuild`
|
* `--superbuild`
|
||||||
build the superbuilds related to the project
|
build the superbuilds related to the project
|
||||||
* `--clear`
|
* `--clear`
|
||||||
clear previous commands before adding this command
|
clear previous commands before adding this command
|
||||||
* `--regex-include <arg>` or `-i <arg>`
|
* `--regex-include <arg>` or `-i <arg>`
|
||||||
only build on builders matching `<arg>` (a Python regular
|
only build on builders matching `<arg>` (a Python regular
|
||||||
expression)
|
expression)
|
||||||
* `--regex-exclude <arg>` or `-e <arg>`
|
* `--regex-exclude <arg>` or `-e <arg>`
|
||||||
excludes builds on builders matching `<arg>` (a Python regular
|
excludes builds on builders matching `<arg>` (a Python regular
|
||||||
expression)
|
expression)
|
||||||
|
|
||||||
@ -451,7 +475,7 @@ will stop running so that you can make changes. Make the changes you need,
|
|||||||
use `git add` to stage those changes, and then use
|
use `git add` to stage those changes, and then use
|
||||||
|
|
||||||
$ git rebase --continue
|
$ git rebase --continue
|
||||||
|
|
||||||
to have git continue the rebase process. You can always run `git status` to
|
to have git continue the rebase process. You can always run `git status` to
|
||||||
get help about what to do next.
|
get help about what to do next.
|
||||||
|
|
||||||
|
BIN
docs/build_stage.png
Normal file
BIN
docs/build_stage.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 54 KiB |
BIN
docs/external_stage.png
Normal file
BIN
docs/external_stage.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 50 KiB |
Loading…
Reference in New Issue
Block a user