Skip to content
GitLab

Contribution workflow · Changes

Page history
Update Contribution workflow authored by Damien Dosimont's avatar Damien Dosimont
Hide whitespace changes
Inline Side-by-side
Contribution-workflow.md
View page @ e821e2a8
If you develop new features in Alya, you should regularly add new tests to the testsuite to validate that such a feature works as expected, but also that nobody breaks this feature when contributing to Alya. We won't accept complaints from someone whose Alya features are not evaluated by the testsuite, because it is not reasonably possible to determine all the interweaving between Alya components and the impact of a modification on the whole code behavior without automatic testing. Nevertheless, regarding the developer, we don't validate either the following assertion: _because Alya passes the testsuite, my contribution is of good quality_. Any contribution should be thought, designed carefully without interfering with the normal behavior of Alya, and if possible mentioned to the design team through the issues, not relying only on the testsuite result.
# Testing philosophy
When you develop new features in Alya, you should regularly add new tests to the testsuite to validate that such a feature works as expected, but also that nobody breaks this feature when contributing to Alya. We won't accept complaints from someone whose Alya features are not evaluated by the testsuite, because it is not reasonably possible to determine all the interweaving between Alya components and the impact of a modification on the whole code behavior without automatic testing. Nevertheless, regarding the developer, we don't validate either the following assertion: _because Alya passes the testsuite, my contribution is of good quality_. Any contribution should be thought, designed carefully without interfering with the normal behavior of Alya, and if possible mentioned to the design team through the issues, not relying only on the testsuite result.
# Git
Even if git is not new, its usage can be quite difficult to apprehend for people mainly used to svn. We will provide some git commands in this tutorial, but we **invite you strongly** to read information about how to use git and get familiar with it as soon as possible.
# Add a new test or modify an existing one
Tests are located to the following path:
```
svn co svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/tests
## Create your working git branch
Get the git tests repository
```sh
git clone git@gitlab-internal.bsc.es:alya/alya-tests.git
cd alya-tests
```
If you already have it, update it:
```sh
git pull
```
svn co file:///gpfs/projects/bsc21/svnroot/AlyaTS/tests
The `master` branch is protected, so you won't be allowed to modify it. Create a new branch with the name of your choice, let's say `mytests`:
```sh
git checkout -b mytests
```
However, you cannot contribute to this repository. So you will have to create a new branch as it follows:
or just switch to this branch if it already exists:
```sh
git checkout mytests
```
svn copy svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/tests svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/branches/[mytests]
Don't forget to update your already existing branch with the last version of the master:
```sh
git merge master
```
replacing `mytests` by the name you want, and checkout it:
Push your branch so it will be accessible for the testsuite.
If it is your first push:
```sh
git push -u origin mytests
```
svn co svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/branches/[mytests]
else:
```sh
git push
```
If you already have your own tests branch, update it using the merge command:
## Modify an existing test
Go to the test directory located in the repository, and modify the test files and the test `.json` consequently.
Add all the files you added and modified to the git tracked files using:
```sh
git add file1 file2 file3
```
svn update
svn merge svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/tests
svn commit
**Do not add files that have been generated by an execution of Alya!**
Commit your changes:
```sh
git commit
```
## Modify an existing test
and push them:
Go to the test directory, and modify the test files and the test `.json` consequently.
Then, commit, and run a testsuite on your test branch to validate your changes. Once it's done, ask the admin to reintegrate your changes. The admin automatically receives the testsuite emails (if you run it on your machine) so you won't have to justify that it ran with success.
```sh
git push
```
Last, run a testsuite on your test branch `mytests` to validate your changes. Once it's done, ask the admin for a (merge)[https://gitlab.bsc.es/alya/alya-tests/merge_requests] using the gitlab merge request interface. The admin automatically receives the testsuite emails (if you run it on your machine) so you won't have to justify that it ran with success.
## Add a new test
Go to the test directory that is the most appropriate (for instance `fast/nastin` if your test is related to a nastin feature), and add a new directory and `.json` file the same way it is done for the existing tests.
Add the files to the svn repository and commit them. Follow the same process as for modifying a test.
If your test needs to be discarded for specific builds (for instance, your test depends on i4 and you want to discard it for i8), you will have to modify the `AlyaTS/Trunk/ServerConfig/` related configuration file and add your test to the list of excluded tests. Since you cannot modify the Trunk directly, you will need to create a new branch:
## Testsuite configuration
If your test needs to be discarded for specific builds (for instance, your test depends on i4 and you want to discard it for i8), you will have to modify the related configuration file and add your test to the list of excluded tests in the testsuite repository https://gitlab.bsc.es/alya/alya-testsuite/. Since you cannot modify the master directly, you will need to create a new branch the same way you did it for the `alya-tests` git repository:
Get the git testsuite repository
```sh
git clone git@gitlab-internal.bsc.es:alya/alya-testsuite.git
cd alya-testsuite
```
If you already have it, update it:
```sh
git pull
```
The `master` branch is protected, so you won't be allowed to modify it. Create a new branch with the name of your choice, let's say `mytestsuite`:
```sh
git checkout -b mytestsuite
```
or just switch to this branch if it already exists:
```sh
git checkout mytestsuite
```
Don't forget to update your already existing branch with the last version of the master:
```sh
git merge master
```
Push your branch.
If it is your first push:
```sh
git push -u origin mytestsuite
```
svn copy svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/Trunk svn+ssh://bsc21***@mn3.bsc.es/gpfs/projects/bsc21/svnroot/AlyaTS/branches/[mytestsuite]
else:
```sh
git push
```
modify the appropriate configuration files located in `serverConfig`.
Run a testsuite so you validate your modifications do not break its behavior.
Then, add the modified configuration files to the list of tracked file:
```sh
git add configFile1 configFile2
```
Commit:
```sh
git commit
```
And push:
```sh
git push
```
modify and commit the files, configure and run the testsuite from this branch `mytestsuite` and ask your admin to reintegrate it.
\ No newline at end of file
Ask your admin to (merge)[https://gitlab.bsc.es/alya/alya-testsuite/merge_requests] your branch.
\ No newline at end of file