Thanks for your interest in contributing to this project!
The following is a set of guidelines for contributing to this library. Most of them will make the life of the reviewer easier and therefore decrease the time required for the patch be included in the next version.
Alfresco has an active forum to support community users of our products. If you have any questions then this is the fastest method of getting an answer.
If you want to raise an issue then please use the issue tracker on GitHub. We may convert these to Jira tickets before working on them, as this is the system we use internally for tracking development. The Jira project for this codebase is SEARCH and you may want to look here first to see if your issue has previously been encountered.1 There are some guidelines for raising a good issue here.
We have a coding standards guidelines page although you will find numerous examples where we have not adhered to them. Please try to maintain consistency with the guidelines for new code, but avoid reformatting large blocks of code if these are not related to your change.
Our codebase consists of long-lived release branches and short-lived feature branches. The
code that we expect to include in the next minor version is stored on master. All other
release branches have the prefix release/. Feature branches may have any other prefix,
but we usually use feature/ or fix/. We expect code on release branches to be ready
to release, and in the rare occasion when a release branch is broken then we try to revert
changes to fix the branch as soon as possible.
As bug fixes often also need a change to ACS then we use a cherry-pick strategy to get the
fix to all necessary release branches. The fix should initially be merged to master and
it can then be cherry-picked back by using:
git cherry-pick -x -m 1 [mergeCommitId]
Pull requests to our community mirror will be accepted in our enterprise codebase and then mirrored back to the community. You will always be credited with your commits, although if you sign your commits then the signature will be stripped by the mirroring process.2
Our builds are currently in our internal Bamboo instance. If you have access to the internal code then you can find some more links in the insight engine module.
Although the build results are not visible externally, it should be possible to run most of
the tests locally. We have divided our tests into unit tests, integration tests and
end-to-end tests. The unit and integration tests can be run using the maven test and
verify goals respectively. The end-to-end tests cannot currently be run externally as
they require some dependencies stored in our internal Nexus.
Footnotes
-
Note that while we try to keep our Jira issues visible to everyone, some are restricted as they relate to specific customers or security issues. Some older issues are also restricted simply because we have not been through to check if they contain sensitive information or not. ↩
-
This is the reason that pull requests submitted by Dependabot appear closed rather than merged. ↩