Skip to content

Commit

Permalink
Update Travis-CI-related content
Browse files Browse the repository at this point in the history
  • Loading branch information
ctrueden committed Apr 13, 2023
1 parent 9bf4199 commit 9fe3b12
Show file tree
Hide file tree
Showing 11 changed files with 13 additions and 135 deletions.
2 changes: 1 addition & 1 deletion _pages/contribute/fiji.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,7 +98,7 @@ Furthermore, for backwards-compatibility a version can be automatically deduced:

- The minimum requirement for core Fiji projects is to use a build system (e.g., [Maven](/develop/maven) or Gradle) that automatically deploys required artifacts to the [SciJava Maven repository](/develop/project-management#maven), such that they can be consumed by downstream code, including other Fiji projects. Required artifacts to deploy include the main JAR and POM files, `-tests` JAR, `-sources` JAR and `-javadoc` JAR.
- To facilitate this, most Fiji projects inherit a common Maven configuration from the [pom-fiji](https://github.com/fiji/pom-fiji) parent project. This configuration ensures that not only the compiled *.jar* files are deployed, but also the Javadocs and the sources. Therefore, it is strongly encouraged to extend this parent; see the [Maven component structure](/develop/architecture#maven-component-structure) section for details.
- All of Fiji's components are deployed by [Travis CI](/develop/travis) to the [SciJava Maven repository](/develop/project-management#maven) or to [OSS Sonatype](http://oss.sonatype.org/). That way, all Fiji components can be added easily as dependencies to downstream projects.
- All of Fiji's components are deployed by [CI/CD](/develop/ci) to the [SciJava Maven repository](/develop/project-management#maven) or to [OSS Sonatype](http://oss.sonatype.org/). That way, all Fiji components can be added easily as dependencies to downstream projects.
- All Fiji components are declared in the toplevel [fiji](https://github.com/fiji/fiji) project's POM as dependencies, and declared in the [pom-fiji](https://github.com/fiji/pom-fiji) parent as *managed dependencies*, as part of Fiji's [Bill of Materials](/develop/architecture#bill-of-materials).

# Guidelines
Expand Down
2 changes: 1 addition & 1 deletion _pages/develop/ci.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ There are several popular options for performing CI builds in the cloud, or on y

* [GitHub Actions](/develop/github-actions) - Used by most SciJava projects for builds, testing, and deployment.
* [AppVeyor](/develop/appveyor) - Used by a few SciJava projects for builds on the Windows platform.
* [Travis CI](/develop/travis-ci) - Used by SciJava projects from 2017 until 2021.
* [Travis CI](/develop/travis) - Used by SciJava projects from 2017 until 2021.
* [Jenkins](/develop/jenkins) - Used by SciJava projects from 2010 until 2019.

Just to name a few that are or were used within the ImageJ community.
2 changes: 1 addition & 1 deletion _pages/develop/philosophy.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ ImageJ and Fiji, in contrast, use the ***RERO*** style of releases, with compati

ImageJ subscribes to the {% include wikipedia title='Release early, release often' text='release early, release often' %} (RERO) mantra often cited in software engineering circles. In particular—and especially because there is a small core development team—the project is driven by [Boyd's Law of Iteration](http://blog.codinghorror.com/boyds-law-of-iteration/): **speed of iteration beats quality of iteration**. That is not to say that we do not strive for quality—we do. But we have found through experience that more releases, together with guiding user feedback, push a project forward more efficiently than a slower release cycle does.

To ensure releases can happen quickly, each SciJava component is independently released and versioned, using [reproducible builds](/develop/architecture#reproducible-builds) with a "release ready" `master` branch. This allows individual SciJava components to be released with the [push of a button](/develop/travis), in a *timespan less than five minutes*. This puts bug-fixes into the hands of users as quickly as possible.
To ensure releases can happen quickly, each SciJava component is independently released and versioned, using [reproducible builds](/develop/architecture#reproducible-builds) with a "release ready" `master` branch. This allows individual SciJava components to be released with the [push of a button](/develop/ci), in a *timespan less than five minutes*. This puts bug-fixes into the hands of users as quickly as possible.

## Convention over configuration

Expand Down
2 changes: 1 addition & 1 deletion _pages/learn/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,7 @@ Over the years we evolved a development style as follows:

This development style has been adopted by the [ImageJ2 team](/people), with two additions (making the fall-out step much smaller):

- tests are added as automated regression tests (to be run by the [continuous integration](/develop/travis) whenever new changes were pushed) whenever possible.
- tests are added as automated regression tests (to be run by the [continuous integration](/develop/ci) whenever new changes were pushed) whenever possible.
- merges are usually done with `--no-ff`, so that even fast-forwarding branches (i.e. rebased on top of *master*) will get a merge commit in which the branch is described more broadly.

See also [coding style](/develop/coding-style).
Expand Down
2 changes: 1 addition & 1 deletion _pages/libs/imglib2/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ It provides an interface-driven design that supports numeric and non-numeric dat

You can find the source {% include github org='imglib' repo='imglib2' %}.

There is also a continuous integration system that builds ImgLib2 [every time the code changes](https://travis-ci.org/imglib/imglib2).
There is also a [continuous integration](/develop/ci) system that builds ImgLib2 [every time the code changes](https://github.com/imglib/imglib2/actions).

## ImgLib2 vs. ImgLib1

Expand Down
4 changes: 2 additions & 2 deletions _pages/licensing/open-source.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,8 @@ Further, we strive for ImageJ to be a community driven project. It is not merely
- Public [issue trackers](/develop/project-management#issue-tracking).
- Public [communication channels](/discuss/#ways-to-get-help) for open discussion.
- Public [wiki](/) for community contributed content.
- [Travis CI](/develop/travis), ImageJ's public {% include wikipedia title='Continuous integration' text='continuous integration'%} system.
- Public [Maven repository](/develop/project-management#maven) for ImageJ binaries.
- Public [CI/CD](/develop/ci) for automated QA and deployment of binary builds.
- Public [Maven repository](/develop/project-management#maven) for serving binaries.

Using these resources, you can always observe the latest progress of the project, get an idea of where the project is heading, contribute code to the project yourself using GitHub, or write documentation, tutorials and other information on the wiki.

Expand Down
2 changes: 1 addition & 1 deletion _pages/news/2010-12-26-imagej2-status-update.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ The following is a status update on the [ImageJ2](/software/imagej2) project as

#### Unit tests

We have created {% include github org='imagej' repo='ij1-tests' label='extensive unit tests' %} for approximately 40 of ImageJ's core classes. These tests are useful for verifying that new versions of ImageJ still perform identically to previous versions. The tests are fully automated, and run whenever we make a change to the ImageJ codebase, via our [Hudson continuous integration system](/develop/travis).
We have created {% include github org='imagej' repo='ij1-tests' label='extensive unit tests' %} for approximately 40 of ImageJ's core classes. These tests are useful for verifying that new versions of ImageJ still perform identically to previous versions. The tests are fully automated, and run whenever we make a change to the ImageJ codebase, via our [continuous integration system](/develop/ci).

#### ImageJ2 architecture

Expand Down
2 changes: 1 addition & 1 deletion _pages/news/2016-01-29-knime-image-processing-hackathon.md
Original file line number Diff line number Diff line change
Expand Up @@ -125,7 +125,7 @@ PlotData=

### Mark Hiner

- Wrote a guide for developers ([Automatic Update Site Uploads](/update-sites/automatic-uploads)) on how to automatically upload to their update site via Travis
- Wrote a guide for developers ([Automatic Update Site Uploads](/update-sites/automatic-uploads)) on how to automatically upload to their update site
- Proof-of-concept'd restoring the Add Imports functionality to the script editor ({% include github org='imagej' repo='imagej-ui-swing' pr='67' label='imagej/imagej-ui-swing\#67' %})
- Added Renjin-flavored R scripting to ImageJ ({% include github org='scijava' repo='scripting-renjin' label='scijava/scripting-renjin' %})
- Got the Fiji downloads migrated to Java 8 bundles (see [Downloads](/downloads))
Expand Down
1 change: 0 additions & 1 deletion _pages/plugins/kymograph-builder.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,6 @@ You can script the plugin. Here is an example:
- [Multi_Kymograph](/plugins/multi-kymograph) : The first kymograph bundled with Fiji, with support for multiple Line ROIs
- Source code on GitHub : https://github.com/fiji/KymographBuilder
- Maven : https://maven.scijava.org/#nexus-search;quick~kymographbuilder
- Travis CI : https://travis-ci.org/fiji/KymographBuilder

## Authors

Expand Down
2 changes: 1 addition & 1 deletion _pages/plugins/trackmate/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -319,7 +319,7 @@ As much as possible we try to include share their code source on a common GitHub

#### Downloadable jars

Thanks to Travis, the extension we are aware of are built automatically and can be downloaded following the links below. They point to a simple .jar file that you just have to drop in your *Fiji.app/jars* folder. TrackMate will recognise the extra modules it ships and will integrate them in the plugin.
Thanks to [continuous integration](/develop/ci), the extensions we are aware of are built automatically and can be downloaded following the links below. They point to a simple .jar file that you just have to drop in your *Fiji.app/jars* folder. TrackMate will recognise the extra modules it ships and will integrate them in the plugin.

| Extension name | Content | Authors | Link to jar file | Source code |
|--------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
Expand Down
127 changes: 3 additions & 124 deletions _pages/update-sites/automatic-uploads.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,10 @@ nav-links: true
nav-title: Automatic Uploads
---

{% include notice icon="info" content='This guide is intended for maintaining non-core update sites by automating builds with [GitHub Actions](https://docs.github.com/en/actions) or [Travis CI](https://travis-ci.com/).
- The [core update sites](/update-sites/core-uploads) are updated manually or automatically. Automated update is performed with [GitHub Actions](https://docs.github.com/en/actions) since July 2021, before that [Travis CI](/develop/travis) was used.
- GitHub Actions and Travis CI are useful because they can freely build any open source project with minimal effort.' %}
{% include notice icon="info" content='This guide is intended for maintaining non-core update sites by automating builds with [GitHub Actions](https://docs.github.com/en/actions).
- The [core update sites](/update-sites/core-uploads) are updated manually or automatically. Automated update is performed with [GitHub Actions](https://docs.github.com/en/actions).
- GitHub Actions is useful because it can freely build any open source project with minimal effort.' %}

# GitHub Actions
## Requirements

- An open-source project hosted on [GitHub](/develop/github)
Expand Down Expand Up @@ -88,123 +87,3 @@ This is also true if you have custom scripts, macros, etc... if these files are
1. You are configuring GitHub Actions to upload the state of an ImageJ installation to your update site. The ImageJ2.app that will be uploaded is located at `./Fiji.app` with respect to the current working directory of the virtual machine GitHub Actions is running on. If your build artifacts are not located in the `./Fiji.app/jars` or `./Fiji.app/plugins` directory, or you don't manually copy scripts to the correct location, ImageJ will see these items as having been deleted—**effectively removing all content from your update site.** You can mitigate this danger by customizing your `release.yml` to download your own update site into the base ImageJ2.app; only changes to the update site state will be uploaded.
2. By default—building the master branch of your repository—your update site will be updated with **every change** to the source code. Although we encourage the master branch to be \"[release ready](/develop/releasing#phase-2-on-master)\", a safer practice would be to configure GitHub Actions to [only build specific events](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)—and set it to build [release versions](/develop/architecture#reproducible-builds) only—e.g. with a release version integration branch.
3. Using the Maven-based `release.yml` as suggested implies that you are conforming to the managed dependencies of the parent pom.xml. If you are not staying up-to-date with the ImageJ and Fiji update sites (by using the latest ImageJ or Fiji [bill of materials](/develop/architecture#bill-of-materials)) then this automation may break your own update site." %}



# Travis CI
## Requirements

- An open-source project hosted on [GitHub](/develop/github)
- Logging in to [Travis CI](https://travis-ci.com/) with your corresponding GitHub account
- [Travis command line tools](https://github.com/travis-ci/travis.rb#installation)
- An [initialized upload password](/update-sites/setup#creating-a-hosted-update-site).

## Additional resources

- [Travis CI user guide](https://docs.travis-ci.com/user/getting-started/)

## Automatic Uploads via Travis CI

Travis CI can be used to automatically build a repository in response to code changes. To ease the maintenance of ImageJ update sites, we can use Travis to automatically upload the latest version of a site. This is done by creating a `.travis.yml` file in your update site's GitHub repository that does the following:

1. Create a fresh ImageJ2.app
2. Build the update site's repository and move the required artifacts (e.g. `.jars`) to their intended locations in the ImageJ2.app
3. Upload the local update site state to your Wiki update site

As a starting point you can copy the following `.travis.yml` :

```yml
language: java
sudo: false

cache:
directories:
- $HOME/.m2/

install:
- mvn package

script:
- ./.travis-deploy.sh

branches:
only:
- master
```

and this script `.travis-deploy.sh` :

```shell
#!/usr/bin/env sh
set -e

# Define some variables
export USER="Username"
export UPDATE_SITE="/update-sites"

export IJ_PATH="$HOME/Fiji.app"
export URL="http://sites.imagej.net/$UPDATE_SITE/"
export IJ_LAUNCHER="$IJ_PATH/ImageJ-linux64"
export PATH="$IJ_PATH:$PATH"

# Install ImageJ
mkdir -p $IJ_PATH/
cd $HOME/
wget --no-check-certificate https://downloads.imagej.net/fiji/latest/fiji-linux64.zip
unzip fiji-linux64.zip

# Install the package
cd $TRAVIS_BUILD_DIR/
mvn clean install -Dscijava.app.directory=$IJ_PATH -Ddelete.other.versions=true

# Deploy the package
# Deploy the package
$IJ_LAUNCHER --update edit-update-site $UPDATE_SITE $URL "webdav:$USER:$WIKI_UPLOAD_PASS" .
$IJ_LAUNCHER --update update
$IJ_LAUNCHER --update upload --update-site $UPDATE_SITE --force-shadow jars/YOUR-FILE.jar
```

Don't forget to replace

```shell
export USER="Username"
export UPDATE_SITE="/update-sites"
```

by your informations.

### Encrypting your password

To upload to your wiki update site, you will need to provide Travis CI with a `WIKI_UPLOAD_PASS` environment variable, which should evaluate to the [upload password](/update-sites/setup#creating-a-hosted-update-site) of the Wiki account performing the upload. To do so securely, follow the instructions on the [encrypting environment variables](https://docs.travis-ci.com/user/environment-variables/#Encrypting-Variables-Using-a-Public-Key).

Note that when you run:

```shell
$ travis encrypt WIKI_UPLOAD_PASS=super_secret --add env.matrix
```

in your repository, the `.travis.yml` will automatically be updated appropriately. You can simply commit and push the changes.

### Non-Mavenized Files

Travis CI is capable of building many languages besides Java. If you cannot use Maven with a `scijava.app.directory` then you need to replace the following line of your `.travis.yml`:

```shell
mvn clean install -Dscijava.app.directory="$(pwd)" -Ddelete.other.versions=true
```

with a sequence of commands that will move your build artifacts to the appropriate `/jars` or `/plugins` directory, as appropriate for your update site.

This is also true if you have custom scripts, macros, etc... if these files are not present in the correct locations of the local ImageJ2.app, they will appear to have been deleted.

## Caveats

{% include notice icon="warning" content="**USE CAUTION HERE**

1. You are configuring Travis CI to upload the state of an ImageJ2 installation to your update site. The current working directory IS the ImageJ2.app that will be uploaded. If your build artifacts are not located in the `jars` or `plugins` directory, or you don't manually copy scripts to the correct location, ImageJ will see these items as having been deleted—**effectively removing all content from your update site.** You can mitigate this danger by customizing your `.travis-deploy.sh` to download your own update site into the base ImageJ2.app; only changes to the update site state will be uploaded.
2. By default—building the master branch of your repository—your update site will be updated with **every change** to the source code. Although we encourage the master branch to be \"[release ready](/develop/releasing#phase-2-on-master)\", a safer practice would be to configure Travis CI to [only build specific branches](https://docs.travis-ci.com/user/customizing-the-build/#Building-Specific-Branches)—and set it to build [release versions](/develop/architecture#reproducible-builds) only—e.g. with a release version integration branch.
3. Using the Maven-based `.travis.yml` as suggested implies that you are conforming to the managed dependencies of the parent pom.xml. If you are not staying up-to-date with the ImageJ and Fiji update sites (by using the latest ImageJ or Fiji [bill of materials](/develop/architecture#bill-of-materials)) then this automation may break your own update site." %}

## See Also

- [Travis use](/develop/travis)

0 comments on commit 9fe3b12

Please sign in to comment.