An internal repository with source code and testcases should act as a base for active development (SVN, HG, Git). A corresponding project on any open source portal with an decentralized repository (SVN, HG, Git) should be synced with tested sources.
An automatic (more or less instant) synchronization between the active developed version on the internal repository and the remote repository on the open source portal.
- Testcases of any kind
- Maven (e.g. generation of project-websites and jars)
- A continuous integration server
- An internal SVN-repository
- A remote Git-repository
1. [If not a suitable job to the project exists within the CI:] Create a job. Log in the server and go the location of the workspace to establish the first connection. Within Jenkins, the path is jenkins/jobs/JOB/workspace.
2. First, we need to establish a Git-SVN connection similar to this article.
3. After setting up a Git repository on the CI, the workflow of synchronization works as follows:
3.1. Getting the data from the svn:
The data is loaded in the remove branch: refs/remotes/git-svn.
Since we need the branch only for reading, we can directly switch to this remove branch.
3.2. Execute your maven goals (clean _deploy_in our case):
The data is pushed to the maven-repo directly.
3.3. After successful execution, everything should be merged and pushed to the Git-repo:
Note that no merge errors should occur since Git-repos are user-bound normally. If you are working on your Git-data as well as on the SVN, you have to tackle merging errors. Otherwise, the workflow above handles publishing of internal repos to open source portal very efficiently since only tested source-code is published even though the different commits stay retrieval over the history: Only the last push must be handled by a specific user.