Contains instructions to perform various release steps in the Release Plans.

Initial Backward Compatibility Check

This initial step checks if the previous release cycle, or more recent bugfix releases done since, have properly set the xwiki.compatibility.previous.version property in the top level POM of xwiki-commons (for the branch you are currently releasing).

For example, if the current release to be made is for 4.2-milestone-3 and, in the meanwhile, there have been released bugfix versions for 4.1 (4.1.4 being the latest released), you need to ensure that the value for xwiki.compatibility.previous.version is 4.1.4.

Verify JIRA issue

If there are opened JIRA issues for the version you are currently releasing (fixVersion is set to the current release), you have two options:

  1. The issue has no code committed yet (Commits tab shows nothing). In this case, you need to push the issue to the next development version. (e.g. fixVersion = 6.3-milestone-1 will be moved to fixVersion = 6.3-milestone-2)
  2. There is some code already committed (Commits tab is not empty). In this case, you need to contact the assigned developer of the issue and find out if the committed code is complete:
    1. If the code is complete, you can close the issue (or ask the dev to do it)
    2. If the code is not complete, you can close the issue and ask the dev to create a new issue for the remaining work to be done for the next version.

In all cases, all opened issues must be closed before the release can be done.

Log on Release machine

# Get on the maven CI master machine
[email protected]:~$ ssh [email protected]

# Get on the agent machine
[email protected]:~$ a1-1

Set up your identity

The first time

  • Configure your Github profile to add the SSH key of the agent so that the commits can be pushed to Github with your user (To get the agent SSH key, do cat ~/.ssh/ To verify it works, do the following on the agent machine: ssh -T [email protected]. It should reply with Hi <your user id>! You've successfully authenticated, but GitHub does not provide shell access..
  • Create your own GPG key if you don't already have one: gpg --gen-key
  • Publish your public GPG key, if you have not already done so: gpg --keyserver hkp:// --send-key <keyID>
  • Import your GPG key:
    • On your local computer run: gpg --list-secret-keys
    • Export your key in a secret.key file: gpg --export-secret-keys «keyID» > secret.key where keyID is the 8 characters long hexadecimal string on the sec line
    • Copy the secret.key file to the agent machine (you may need to copy to first and then to agent-1-1)
      • From your local computer, upload the key to scp secret.key [email protected]:/home/maven
      • From (/home/maven): scp secret.key [email protected]:/home/hudsonagent
        • You can remove the key from after you have uploaded it to agent-1-1.
        • In case the IP address of the agent written above is no longer correct, just connect to the maven CI master machine (as shown in the Log on Release machine section above), run the command alias and get the IP address from the line containing the "a1-1" alias (the one used to connect to the agent). It looks like alias a1-1='ssh [email protected]'. After that, please update this page emoticon_smile
    • On the agent machine, run gpg --import secret.key
      • Don't leave the key file on the agent or the maven machines. Run rm secret.key on both locations.
  • You need to have a .gitconfig.<yourusername> file. You can do that by copying one of the existing gitconfig file
  • Make sure your gitconfig file has the key signingkey in the [user] section (the value is your key id which you can get with gpg --list-secret-keys).
  • Copy your .gitconfig.<yourusername> file as the main gitconfig file: cp .gitconfig.<yourusername> .gitconfig

The other times

  • Configure your Github profile to add the SSH key of the agent so that the commits can be pushed to Github with your user (To get the agent SSH key, do cat ~/.ssh/ To verify it works, do the following on the agent machine: ssh -T [email protected]. It should reply with Hi <your user id>! You've successfully authenticated, but GitHub does not provide shell access..
  • Make sure previous release manager did not left his GPG key
    gpg --delete-secret-and-public-keys `gpg --list-secret-keys | grep ^sec | cut -d/ -f2 | cut '-d ' -f1`
  • Import your GPG key, run gpg --import secret.key
  • Copy your .gitconfig.<yourusername> file as the main gitconfig file: cp .gitconfig.<yourusername> .gitconfig

Script to automatize this step

  1. Put this script on your local machine. 
  2. Replace the USER_NAME variable. 
  3. Make sure you have exported your secret key in a file called secret.key in your user directory. 
  4. Don't forget to give execution right to the file. 
  5. Execute and enjoy!


function log {
       ## Colors


log "Copy secret key to the maven machine"
scp ~/secret.key "[email protected]:/home/maven/${USER_NAME}.key"

log "Put it on the agent1-1"
ssh [email protected] "scp /home/maven/${USER_NAME}.key [email protected]:/home/hudsonagent"

log "Delete it from"
ssh [email protected] "rm /home/maven/${USER_NAME}.key"

log "Import the key in agent1-1"
ssh [email protected] "ssh [email protected] 'gpg --import /home/hudsonagent/${USER_NAME}.key'"

log "Delete it from agent1-1"
ssh [email protected] "ssh [email protected] 'rm /home/hudsonagent/${USER_NAME}.key'"

log "Copy gitconfig"
ssh [email protected] "ssh [email protected] 'cp /home/hudsonagent/.gitconfig.${USER_NAME} /home/hudsonagent/.gitconfig'"

log "Display agent1-1 SSH key (to put on"
printf "\033[0;91m\033[0;100m"
ssh [email protected] "ssh [email protected] 'cat /home/hudsonagent/.ssh/'"

log "Connect to hudsonagent"
ssh -tt [email protected] "ssh -tt [email protected]"

Update Release scripts

# Update the release script
[email protected]:~$ cd xwiki-dev-tools ; git pull --rebase ; cd ..
Do a git status to verify that there are not any committed but not pushed stuff lying around...

Configure the Java Version

Depending on which branch you are releasing from you may have to use a different Java version than what is used on master. To change the Java version you need to remove the "java" symbolic link from the home folder and recreate it to point to the "javaX" folder that corresponds to the Java version you have to use.

# See what Java versions are available.
[email protected]:~$ ls -al | grep java
# Change the Java version
[email protected]:~$ rm java
[email protected]:~$ ln -s java7 java
# See if the change has been taken into account.
[email protected]:~$ java -version

Update Translations

When you release a .x version (bug fix release), be very careful when you update translations because the new ones might concern new stuff introduced in the master branch. The issue is that the translations wiki does not support branches.

Perform the following steps:

  • Updating translations takes a while (1h+) so you should first check if there is anything to update. Compare the date of the latest translation with the date of the previous release. If the previous release is more recent then you can skip updating the translations.
  • Edit the file to set branch, if needed (e.g. do this only if you are performing a bugfix release like 6.1.1 on the stable-6.1.x branch and you are not working on master, which is 6.2-SNAPSHOT).:
    [email protected]:~$ vim
  • Move to xwiki-trunks:
    [email protected]:~$ cd releases/xwiki-trunks/
  • Download the translations:
    [email protected]:~/releases/xwiki-trunks$ ~/
  • Review the changes for anything amiss, like spam in translations.
    • You need to go through each project (xwiki-commons, xwiki-rendering, xwiki-platform, and xwiki-enterprise for the 8.x branch)
    • Do a git status to spot changes (and the list of updated languages).
      • Do a git diff and visually review modified translation keys and spot problems (like spam). Do not spend too much time here, a quick scan is enough to spot obvious problems.
      • For new (untracked) translation files, you can view them individually with a standard cat <filePath> command.

        In case there are new translation files for GWT modules (xwiki-platform-gwt-user or xwiki-platform-wysiwyg-client), those languages need to be added to the corresponding GWT module descriptors:

        ## For xwiki-platform-gwt-user
        vim xwiki-platform-core/xwiki-platform-gwt/xwiki-platform-gwt-user/src/main/resources/org/xwiki/gwt/user/User.gwt.xml
        ## For xwiki-platform-wysiwyg-client
        vim xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-client/src/main/resources/org/xwiki/gwt/wysiwyg/Wysiwyg.gwt.xml

        ...and add the new language code to the existing list defined in the locale extended-property that looks similar to this:

        <extend-property name="locale" values="ca,cs,da,de,es,fr,it,lv,nl,pt_BR,ru,sk,sv,tr,zh,zh_TW" />
      • No need to do a git add at this point since it will be done for all projects below.
    • Collect the list of updated languages by looking at the language code of the modified/new translation files and update the Release Notes in the Translations section with these language codes.
  • Commit the translation changes:
    [email protected]:~/releases/xwiki-trunks$ ~/ commit
Be patient, this process takes some time

Build the release

For Milestone, RC and Final releases

When releasing a Release Candidate (e.g. 6.2-rc-1), make sure that, when asked What is the next SNAPSHOT version?, you do not increment the snapshot version (i.e. you answer 6.2-SNAPSHOT instead of 6.3-SNAPSHOT or whatever suggestion you have). This is because the next step will ask you to create a stable branch where the final version (if this is the last RC we`re doing) will be released and there we need to keep the SNAPSHOT version to the current one.

If you have created the stable branch and are asked What is the next master version?, you will now increment the snapshot version (i.e. answer 6.3-SNAPSHOT) so that the master branch can move to the next development version.

Tip: Because the build process is a lenghty one (currently around 2 hours), it is a good idea to use the screen linux command. This is most helpful in case your Internet connection or electrical power drops. However, it is not in any way mandatory to use screen during the release.
# Perform the release from the release sources
[email protected]:~/releases/xwiki-trunks$ ~/

For Release Candidate releases only

  • Update the commons.version Maven property located in top level pom.xml of the xwiki-commons git repository, on master
  • Only for XWiki < 9.11RC1 Update the continuous integration jobs to build the new stable version that you have just created through the release of a RC version.

Update the continuous integration jobs

This is only for XWiki < 9.11RC1 since starting with XWiki 9.11RC1 we're using Jenkinsfile to automatically sync Jenkins jobs with Git branches! emoticon_smile

At this point, you have just created a new stable-x.y.z branch in the source repository where your version will achieve final version and will continue stabilizing trough bugfix versions, while the main development branch is done on the master branch.

However, the continuous integration jobs that are supposed to build the stable-x.y.z branch are not yet set up. They are still configured to build the previous stable branch (stable-x.y-1.z or stable-x-1.y.z). This means that you need to add the new jobs. Fortunately we have an automated script for this emoticon_wink

Go to , fill the parameter values and click on Run at the bottom right. 

Fix the "Projects to watch" (in the "Build Triggers" section) in each new job to add the right version suffix.

Restart the release

If the build failed or if you wish to release again, perform the following steps:

  • Set the version that you're building, e.g. [email protected]:~/releases/xwiki-trunks$ export VERSION='4.2-milestone-3'
  • Navigate to the repositories that failed to build (e.g. xwiki-platform) and clean up. For example for xwiki-platform:
    [email protected]:~/releases/xwiki-trunks$ cd xwiki-platform
    [email protected]:~/releases/xwiki-trunks/xwiki-platform$ ~/
  • Edit the script and comment out the previously successfully released repositories so that you don't release them again.
    [email protected]:~/releases/xwiki-trunks/xwiki-platform$ cd ..
    [email protected]:~/releases/xwiki-trunks$ vim ~/

    Go to the end of the file and scroll up, until you reach this section:

    # Wrapper function that calls release_project for each XWiki project in order: commons, rendering, platform, enterprise, manager.
    # This is the main function that is called when running the script.
    function release_all() {

    Inside this method, comment out the previously successful top level projects and leave uncommented the top level projects that still need to be released, including the one we are resuming from. In this example, we are resuming from xwiki-platform but xwiki-commons and xwiki-rendering were already successfully released, so we are skipping them:

     echo              "*****************************"
     echo -e "\033[1;32m    Releasing xwiki-commons\033[0m"
     echo              "*****************************"
    #  release_project xwiki-commons
     echo              "*****************************"
     echo -e "\033[1;32m    Releasing xwiki-rendering\033[0m"
     echo              "*****************************"
    #  release_project xwiki-rendering
     echo              "*****************************"
     echo -e "\033[1;32m    Releasing xwiki-platform\033[0m"
     echo              "*****************************"
      release_project xwiki-platform
  • Fix the build if need be (you won't need to fix anything if you just want to release again for example).
  • Re-launch the script from /releases/xwiki-trunks to resume from where we left off:
    [email protected]:~/releases/xwiki-trunks$ ~/

Resuming release:perform from a particular module

The instructions below are not applicable for RC releases (that involve working with other branches than master and other additional operations). Would need additional steps to be complete, so it`s safer to just restart from the top level project that failed (i.e. rendering, platform, etc.).

Going even further with the resuming of a failed build, in the case of release:perform, we can resume from the actual failed module. To do so, we must make some additional temporary modifications to the release script, besides the one described above which isolates the script to release only the currently failed module.

This method only applies to a single failed project at a time (e.g. xwiki-platform). Make sure all other projects are commented out in the release_all method.

Do not run the ~/ command on the failed module because release:perform needs that information to be able to resume. Also, remember to cleanup after finishing with the release of the project at hand.

Comment out the cleanup steps done in the release_project method:

function release_project() {
  cd $1
#  pre_cleanup
#  update_sources
#  check_branch
#  create_release_branch
#  pre_update_parent_versions

Comment out the release:prepare step in the release_maven method and add the -rf group:artefactId parameter inside the -Darguments="..." with the module you want to resume the release from. See an example below where we are resuming from org.xwiki.platform:xwiki-platform-distribution-war.

function release_maven() {

 echo -e "\033[0;32m* release:prepare\033[0m"
# mvn release:prepare -DpushChanges=false -DlocalCheckout=true -DreleaseVersion=${VERSION} -DdevelopmentVersion=${NEXT_SNAPSHOT_VERSION} -Dtag=${TAG_NAME} -DautoVersionSubmodules=true -Phsqldb,mysql,pgsql,derby,jetty,glassfish,legacy,integration-tests,office-tests,standalone -Darguments="-N ${TEST_SKIP}" ${TEST_SKIP} || exit -2

 echo -e "\033[0;32m* release:perform\033[0m"
  mvn release:perform -DpushChanges=false -DlocalCheckout=true -P${DB_PROFILE},jetty,legacy,integration-tests,office-tests,standalone ${TEST_SKIP} -Darguments="-P${DB_PROFILE},jetty,legacy,integration-tests,office-tests ${TEST_SKIP} -Dgpg.passphrase='${GPG_PASSPHRASE}' -Dxwiki.checkstyle.skip=true -rf org.xwiki.platform:xwiki-platform-distribution-war" -Dgpg.passphrase="${GPG_PASSPHRASE}" || exit -2

 echo -e "\033[0;32m* Creating GPG-signed tag\033[0m"

Manually set the git tag name that will be used for GPG signing:

## The format is MODULE_NAME-VERSION. Modify accordingly.
export TAG_NAME="xwiki-platform-8.3-milestone-2"

Run the release script to resume the release of the current project:

[email protected]:~/releases/xwiki-trunks/xwiki-platform$ ~/
Cleanup the release script by removing the temporary changes described in this section. This applies if you want to proceed to the next project (e.g. xwiki-enterprise) where the release needs to be executed properly.

Clean up identity

# Git identity
[email protected]:~/releases/xwiki-trunks$ cd
[email protected]:~$ cp .gitconfig.default .gitconfig

# GPG key
[email protected]:~$ gpg --delete-secret-and-public-keys `gpg --list-secret-keys | grep ^sec | cut -d/ -f2 | cut '-d ' -f1`

# Local changes to the release-scripts (, user/password in, etc.)
[email protected]:~$ cd xwiki-dev-tools
# Double check that you are not removing any improvement you have made to the release scripts that should be committed instead ;)
[email protected]:~/xwiki-dev-tools$ git status
[email protected]:~/xwiki-dev-tools$ git diff
[email protected]:~/xwiki-dev-tools$ git checkout .

error Then don't forget to remove the Agent's SSH Key from your Github Account.

Generate Backward Compatibility Report

The Backward Compatibility report is automatically generated in the Release Notes page by the {{backwardCompatiblityReport version="<version>"/}} macro which does the following:

  • Gets the revapi ignores from the pom.xml of xwiki-commons, xwiki-rendering and xwiki-platform GitHub repositories and store them in an xobject in the Release Note page. If you wish to regenerate the content from GitHub just delete this xobject.
  • Displays the ignores

If you're releasing a final version, perform the following operations on your local machine:

  • Checkout the tag you've just released for all Git repositories having java code (xwiki-commons, xwiki-rendering, xwiki-platform)
    $ cd xwiki-commons
    $ git fetch --tags
    # If you`re releasing 4.2
    $ git checkout xwiki-commons-4.2
  • Remove the revapi ignores from the branch and also on master in order to start fresh the next version.
    • You have to remove ignores from 3 locations:
      • xwiki-commons/xwiki-commons-core/pom.xml
      • xwiki-rendering/pom.xml
      • xwiki-platform/xwiki-platform-core/pom.xml
    • Commit the removals:
      # Stash the changes you just did on the tag
      git stash
      # Switch to your branch
      # Assuming you are releasing 6.2.3. If you were releasing 6.3 (a final version), commit both on branch and master
      git checkout master
      # Pop, commit and push your previous changes to master
      git stash pop
      git commit -a -m "[misc] Removed revapi ignores from the previous version"
      git push origin master
      # Switch to your release's branch
      git checkout stable-6.2.x
      # Cherry-pick the changes from master and push to the branch
      git cherry-pick -x master
      git push origin stable-6.2.x
  • Checkout master for xwiki-commons and edit the top level pom.xml to update the xwiki.compatibility.previous.version. Set the value to be your release you've just done.
  • Checkout the xwiki-commons branch corresponding to your release (for example if you're releasing 4.1.3, checkout stable-4.1.x) and cherry-pick the commit you`ve just pushed to master. (git cherry-pick -x master; git push origin stable-4.1.x)

Generate Code Contributors list

  • Collect the list of code contributors for this release by running the following command on each branch that has been released (xwiki-commons, xwiki-rendering, xwiki-platform and xwiki-enterprise):
    > git fetch --tags
    > git log --pretty=format:"%an" <previousTag>..<nextTag> | sort -u
    ## For instance:
    > git log --pretty=format:"%an" xwiki-commons-7.2-milestone-1..xwiki-commons-7.2-milestone-2 | sort -u
    > git log --pretty=format:"%an" xwiki-rendering-7.2-milestone-1..xwiki-rendering-7.2-milestone-2 | sort -u
    > git log --pretty=format:"%an" xwiki-platform-7.2-milestone-1..xwiki-platform-7.2-milestone-2 | sort -u
    > git log --pretty=format:"%an" xwiki-enterprise-7.2-milestone-1..xwiki-enterprise-7.2-milestone-2 | sort -u
    ## For final versions:
    > git log --pretty=format:"%an" xwiki-platform-7.2..xwiki-platform-7.3 | sort -u

    Try to remove duplicates and sort alphabetically.

  • Update the Release Notes in the Credits section with the contributors list.

Push to OW2

  • Log on the Jenkins master machine: ssh [email protected]
  • Go to the release script directory: cd xwiki-release-scripts
  • Create a Release notes file: vim releasenotes-<version>.txt (e.g. releasenotes-6.1-milestone-2.txt)
    This milestone contains a new mail API and module to replace the old mailsender plugin, Flamingo skin and Extension Manager improvements as well as various performances improvements and bug fixes.

    Full release notes available at
  • Upload to OW2 with ./ push_ow2 (Follow instructions)
    • In case there is a problem during the upload and some of the files are not uploaded correctly, you can repeat this step to properly upload all the files.
    • You will need an OW2 account with admin rights on the XWiki project for this step
    • You may experience an "Could not chdir to home directory ... No such file or directory" error message if your account is just minutes old. If so, give it about 10-20 minutes for the new account to properly be created. It may also help (though this is just guesswork based on personal experience) if you register a public SSH key in the account management. Repeat the upload step until the files are all uploaded.
  • Create the release on OW2 with: ./ update_ow2 (Follow instructions) The OW2 forge API has been broken so it does not fully work when pushing distribution files, you will have to do it by hand on until we find a way to fix it emoticon_unhappy
  • Verify all is ok by going to the XWiki project page on OW2. Specifically, verify that the pushed files can be downloaded before continuing with the release process as otherwise end users will get an error when trying to download XWiki.
After update_ow2, OW2 has cron jobs that runs regularly. You need to test the files are available on before proceeding further.

Blog post on

Create a new blog post on You can use the same text that you`ve used in the OW2 release notes or otherwise have a look at the previous release blog posts for inspiration.

Announcement Mail

  • Send the announcement email to the devs list.
  • Example email:
    • Subject: [ANN] XWiki <version> released
    • Content:
      The XWiki development team is proud to announce the availability of XWiki <version>.
      <short summary>

      You can download it here:

      Make sure to review the release notes:<short version>

      Thanks for your support
      -The XWiki dev team

Forum Announcement

  • Add a new post to the users forum on
    • Subject & Content: Same as for mail, but drop the [ANN] prefix
    • Category: News & Events
    • Tags: release

Announce on Twitter

To announce the new release on Twitter using`s account. Use the following type of text:

[email protected]:~$ twidge update "#XWiki 8.4.1 has been #released! Check it out:"

Publish to Maven Central

XWiki Commons and XWiki Rendering need to be published to Maven Central. To do so we use Sonatype's sync. The strategy is to upload to the XWiki Staging repo on Sonatype's Nexus, to check the staged repo and then to promote it.

In order to be able to upload to Sonatype's Nexus you'll need to create an account on and then ask for publish rights (if you don't have them already) by posting a comment to .

  • Add the following in your settings.xml:
  • Add passphrase in settings.xml or pass it on command line using -Dgpg.passphrase=...:
  • in xwiki-commons and in xwiki-rendering, checked out the correct tag
    git pull --rebase --tags
    # If you`re releasing xwiki-commons-7.0
    git checkout xwiki-commons-7.0
  • in xwiki-commons and in xwiki-rendering, after having checked out the correct tag, run:
     mvn clean deploy -Prelease,legacy,standalone,integration-tests -DaltDeploymentRepository=sonatype-nexus-staging::default:: -DskipTests=true -Dxwiki.checkstyle.skip=true
  • Then log in and perform the release steps as indicated on Sonatype's synchro doc.

Rebuild Debian Distribution

The XWiki Debian distribution is automatically rebuilt every day using a crontab on

However, in order for the Debian distribution to be ready when we announce a new version, it's a good thing to force rebuild it.

This is achieved by logging on with the maven user. Then run the script.

nohup /home/maven/ &

This start the index update in the background, you can leave.

Force Extensions Update

In order to have up to date versions on you should trigger the Batch importer scheduler (from the first node of the cluster).

However before you do so, make sure to mute the IRC channel to not spam it:

/mode +q xwikibot

And don't forget to unmute it once the release is over:

/mode -q xwikibot

Update Docker

This should be done only for final versions
  • Create an issue on the XDOCKER project with subject Upgrade stable version to <version>.
  • Update the version of XWiki in the build.gradle file found in the XWiki Docker repository (clone it locally first).
    • To know how to generate the sha256, check the doc inside build.gradle. You need to download in advance the *.war file and run the according command in order to generate.
  • Execute the Gradle build (run ./gradlew) to generate the various Dockerfiles and other resources for all image tags
  • Test the modified files. On Linux, you need to use sudo on each docker command or configure it differently.
    • Install Docker. For Mac you can check the installer.
    • Make sure you open Docker before running the commands.
      • Linux: sudo systemctl start docker (On Ubuntu it should start automatically after install, but on Fedora needs to be started/enabled manually)
    • docker network create -d bridge xwiki-test
    • docker run --net=xwiki-test --name mysql-xwiki-test -v /tmp/xwiki-docker-test/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=xwiki -e MYSQL_USER=xwiki -e MYSQL_PASSWORD=xwiki -e MYSQL_DATABASE=xwiki -d mysql:5.7 --character-set-server=utf8 --collation-server=utf8_bin --explicit-defaults-for-timestamp=1
    • Navigate to the directory to test, e.g. 9/mysql-tomcat and issue:
      • docker build -t xwiki-test .
      • docker run --net=xwiki-test --name xwiki-test -p 8080:8080 -v /tmp/xwiki-docker-test/xwiki:/usr/local/xwiki -e DB_USER=xwiki -e DB_PASSWORD=xwiki -e DB_DATABASE=xwiki -e DB_HOST=mysql-xwiki-test xwiki-test. Note that same as for mysql container above you'll need to remove the container if it already exists.
        • In case you had an XWiki instance running on 8080 and the above command fails (i.e. address already in use), you cannot simply run it again. If you do (and you should try, actually), will try to recreate the container with the xwiki-test name that is now already in use by a container for which you are given the ID (note that down). Instead, you need to simply start the mentioned container ID which previously failed by running docker start <FAILED_START_CONTAINER_ID>.
    • Open your browser to http://localhost:8080 and try to setup XWiki and verify it works
  • If all is ok commit, push and close the jira issue created above
  • Note down the SHA1 of the last commit and update with it by creating a Pull Request (you can edit directly on the GitHub web page and create a Pull Request).
  • If you need to update the official documentation create a Pull Request for (you can edit directly on the GitHub web page and create a Pull Request).
  • Clean up by running the following in a shell:
    docker stop xwiki-test
    docker rm xwiki-test
    docker stop mysql-xwiki-test
    docker rm mysql-xwiki-test
    docker network rm xwiki-test
    docker rmi xwiki-test
    sudo rm -Rf /tmp/xwiki-docker-test/mysql
    sudo rm -Rf /tmp/xwiki-docker-test/xwiki
If you need help, ask Vincent emoticon_smile

Crash course on Docker:

Docker can create Images based on a Dockerfile (or a Compose file). Docker can also download Images from the DockerHub repository. Docker can create Containers from images. Docker also creates internal Volume unless you create mapped Volumes on your host computer so that you can navigate in them as local directories.

  • docker run creates a container locally based on an existing docker image.
  • docker ps lists the ids of running containers
  • docker ps -a lists the ids of all containers (running or not)
  • docker start <id> starts an existing container
  • docker stop <id> stop a running container
  • docker rm <id> removes an existing container
  • docker volume ls lists existing volumes
  • docker volume rm removes an existing volume
  • docker system prune removes unused data
  • docker network create creates a docker network so that several containers can see each other
  • docker network ls lists existing docker networks
  • docker network rm <id> removes an existing docker network
  • docker images lists all local images
  • docker rmi <id> removes an existing local image
Created by Vincent Massol on 2012/07/13 15:39

Get Connected