Release and deployment
Continuous (artifact) deployment in Java
When using Java, Travis CI can be easily configured to publish new snapshot artifacts on commit; to enable this feature, a project committer can follow these simple steps:
- Follow the Java Snapshot deployment configuration ; as a result, you should have username/password credentials (mentioned below as
CI_DEPLOY_PASSWORD) to access issues.sonatype.org
- Email firstname.lastname@example.org to request permission to deploy artifacts on Maven remote repositories; this action is not required if the developer has already been granted access previously
- Commit a
settings.xmlfile in the project root folder
CI_DEPLOY_PASSWORDvariables with Travis CI; make sure that they're encrypted and hidden during the build process; the credentials to use are the ones defined on step 1; if you don't want to share your username/password credentials, you can request and use Nexus tokens
- Change the
mvnbuild command to a. Invoke the
deploygoal b. Append
--settings settings.xmlat the end of the build command
Continuous release in Python
Travis CI can be configured to use python-semantic-release, a package that simplifies and automates versioning for python projects; a project lead can email email@example.com to request Foundation staff to apply the proper Travis CI project settings; packages will be published on behalf of the FINOS pypi user.
Continuous release in NodeJS
Travis CI can easily publish packages to npm using semantic-release.org, which delegates release operations to your CI environment and allows you to control versioning using commits (commitizen); as a result, npm packages will be continuously released on each code repository change.
Follow our instructions on how to register a package and user in the Foundation npm organisation.
GitHub gives the ability to create, reuse and share actions, which can be easily described as workloads that can be triggered on a wide range of events.
Actions can be only defined at repository level, creating a
YAML file in the
.github/workflows folder. The
Actions tab available in
github.com web UI will list the actions defined and show the execution logs.
The Open Developer Platform uses GitHub Actions for the following use cases:
- Building and publishing Project websites
- Tracking meeting attendance
- Validating repository compliance (work in progress)
To learn how to use GitHub Actions, start reading https://help.github.com/en/actions.
When it's time to start writing your first
.yml file, we found extremely helpful the following resources:
Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted at GitHub.
To enable Travis CI on a Foundation hosted project:
- Sign in to Travis CI with your Github credentials
- Access the Travis CI profile and sync your project
- Add a
.travis.ymlfile in the root folder of your GitHub repo (check this .travis.yml as example) a. (optional) If you need to perform variable encryption and other useful commands, install the Travis CI Client (using
gem install travis)
https://travis-ci.org/finos/<repository-name>and validate the build
A badge can be added at the top of the project's root-level
README.md file, using the following Markdown syntax:
Example of Configuring Integration Testing
In order to run this sample (some Symphony sample bots), the Travis build needs to be configured to add the following items:
At this point, the certificates are in place and downloaded into the build box; integration tests can resolve User Identity certificates by accessing environment variables.
- The (hidden) environment variables that identify User Identity certificates (in this case 2, one for the message sender, one for the message receiver)
- The integration test logs of a successful run
Known Certificate Issues
This basically means that the certificate password is wrong; to validate the certificate using the following command:
Reminder for Foundation staff: every password symbol must be escaped by prefixing it with character ‘\’, before setting it as Travis environment variable.
Branch specific build commands
Travis CI does not provide a syntax to specify branch-specific build commands; however, it is possible to use the following
.travis.yml syntax to workaround it; in this example, the Maven build will use the
sonar profile only if the current branch is master.
FINOS can provide projects with Azure Pipelines integration on https://dev.azure.com/finosfoundation.
You can follow docs on the Microsoft docs page
Myget is a friction-free continuous integration & delivery for your nuget, npm, bower and vsix packages; the Foundation provides package repositories, which allow:
- Pre-release build and publishing, using build environments that are equipped with .NET Framework and Visual Studio (headless); it also features source code tagging and version updates on source code based on incremental build number, to fully automate the package publishing pipeline
- Sync with NuGet, that can be either manual (promoting pre-releases to releases using MyGet web interface) or automatic (a committer must create a personal account on MyGet and request access from the Foundation in order to be able to push packages)
In order to request a project to be integrated with MyGet, a Project lead can sign up to MyGet and email firstname.lastname@example.org the following info:
- Project coordinates - GitHub project url and other useful info
- MyGet username
- CSProj and CS files - Where project descriptors are located
- Packages - A list of the packages that need to be published; by default all packages are taken into account
- Publishing strategy to NuGet - Whether to enable automatic publishing based on source code branching or rely on manual package pushing using the MyGet interface; if the latter, a MyGet personal account username must be provided
Badges can be added at the top of the project's root-level
README.md file, using the following Markdown syntax:
- Build status:
- Latest Pre-Release package published: