CI and Releases

Currently, a single CI service is being used: travis-ci.com/filebrowser and we use our wizard script to manage our builds and releases.

Release Procedure

We use semantic versioning. For more info check semver.org.

  1. Manually tag the commit that is going to be used in filebrowser/frontend.

  2. Execute ./wizard.sh -r $semver in filebrowser/filebrowser. It will:

    1. Check if the tag exists in filebrowser/frontend.

    2. Update the submodule to that tag.

    3. Replace untracked with the version in types/version.go.

    4. Commit and tag filebrowser/filebrowser.

    5. Revert the version to untracked and commit again.

  3. When the tag is pushed, Travis will detect it and execute the following procedures:

    1. Run through the linters to check if the code is alright.

    2. Build the frontend and the backend, generating rice-box.go.

    3. If the commit is tagged, then:

      1. Build the release artifacts for all supported platforms and a new docker image (see .goreleaser.yml for more information).

      2. The artifacts are published to GitHub Releases.

      3. The tagged docker image is published to hub.docker.com/r/filebrowser/filebrowser.

      4. The rice-box.go is committed, tagged and then pushed to a branch on filebrowser/caddy which must then be merged by a maintainer.

We would benefit if a PR would be automatically created. It can be done through GitHub REST API although we're not sure how to handle the authentication. If you're willing to help us, please let us know.

‚Äč