Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update README.md #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update README.md #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 15 additions & 26 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,41 +16,39 @@
__OS2Forms__ is a drupal based solution for creating advanced webform functionality for Danish Municipalities.

Solution main repositories:
* Drupal core incl. installatioj profile: https://github.com/OS2Forms/os2forms8
* OS2Forms main module https://github.com/OS2Forms/os2forms
* OS2Forms forløb main module https://github.com/OS2Forms/os2forms_forloeb
* OS2Forms forløb profile: https://github.com/OS2Forms/os2forms_forloeb_profile
* OS2Forms main Drupal module https://github.com/OS2Forms/os2forms

<a name="license"></a>
## License
All OS2Forms projects are using [EUPL v1.2 License](https://opensource.org/licenses/EUPL-1.2).

<a name="testing-and-ci"></a>
## Testing and CI
Every OS2Forms drupal project should have continuous integration builds are performing by [Travis CI](https://travis-ci.org).
To improve code quality and integration possibilities there are using set of following tools:
Every OS2Forms drupal project should have CI build performed by [Github actions](). Your project might have different sets of implmented checks.
To improve code quality and integration possibilities there are recommended to use following tools:
* [PHP_CodeSniffer]() with [Drupal coding standards](https://www.drupal.org/docs/develop/standards/coding-standards) and best practices defined in [Coder module](https://www.drupal.org/project/coder).
* [ESLint](https://eslint.org/) with [Drupal ESLint rules set](https://www.drupal.org/node/1955232).
* [Stylelint](https://stylelint.io/) with rules set defined for Drupal core.
* [Twigcs](https://github.com/friendsoftwig/twigcs) with standard set of rules
for twig templates.
* [Drupal-check](https://github.com/mglaman/drupal-check) to check project
readiness to Drupal 9 via checking of deprecated code usage.
* @TODO [PHPUnit](https://phpunit.de/) test to check key contrib modules tests.
readiness to Drupal 9 via checking of deprecated code usage. (ONLY FOR FULL INSTALLATIONS)

For more details about travis-ci continuous integration builds
see `.travis-ci.yml` file in project git repository.

NOTE: Some projects couldn't have its own PHPUnit test. This is a part of future
development scope.
For more details about github-action builds see:
* YAML files in `.github/workflows` directory of specidif git repository,
* `Actions` tab in github repository.

<a name="git-guideline"></a>
## Git guideline
Project use default approach for branch naming.
For all projects and git repositories there is used default approach with git branching.

If you are in doubt on "What branch you should use?" or "How to create it?" See [Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) tutorial from Atlassian.

### Bracnhes
* `develop` - general development branch (Default).
* `develop-2.x` - development branch for version 2.x. (if requires)
* `master` - stable version of code.
* `master` or `main` - stable version of code.

There are no specific rules for feature branch names. However we recommend
use [OS2Forms JIRA](https://os2web.atlassian.net/browse/OS2FORMS) or
Expand All @@ -66,21 +64,12 @@ Given a version number MAJOR.MINOR.PATCH, increment the:
* MINOR version when you add functionality in a backwards compatible manner, and
* PATCH version when you make backwards compatible bug fixes.

#### Outdated approach
Since OS2Forms projects are Drupal friednly, there was used drupal-friendly
git branch/tag names like 8.x, 8.x-2.x. Please keep use it or ask about changes
in case this names are not compatible with changes you have.

For new repositories it was decided to switch back to github,
composer way to for branch names.

<a name="code-review"></a>
## Code review
New changes or bugfixes in existing codebase have to be added to repository
New features of hotfixes existing codebase have to be added to repository
through general [code review process](https://github.com/features/code-review/).
To request a code review, use the following process:
1. Add Github pull request from the feature/bugfix branch to 8.x or other related dev branch.
2. Request code review from internal department
1. Add Github pull request from the new branch to base branch accordingly with [gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).2. Request code review from internal department
3. Test features with customer on test setting
4. Fix bugs or get approval from customer
5. Request code review from one of project contributor (other department/company).
Expand All @@ -90,7 +79,7 @@ To request a code review, use the following process:
NOTE: There are preconditions that have to be met before accepting a pull request:
- All requested changes have to be done
- All discussion have to be resolved
- Pull request should have green Travis CI build status.
- Pull request should have green CI build status.

<a name="coc"></a>
## Code of Conduct
Expand Down