Getting started
IntroductionInstalled packagesEnvironment variablesDebugging buildsCachingParallel testingDeployment pipelinesRunning commands as rootIgnoring commandsRun a command in case of an errorSetting timezoneAccess to other repositoriesUsing scriptsGit LFSUbuntu 20.04 Focal
IntroductionFTP/SSH/SFTP/RSYNCCustom scriptHerokuHeroku MigrationAWS Elastic BeanstalkAWS CodeDeployAWS LambdaAWS S3Google App EngineAWS CLIgcloud CLIAzure CLIDigital OceanEngine YardCapistranoGit PushCloudFoundryCloud66anynines
IntroductionBrowser testingBackground commandsGit submodulesCustom DNSArtifacts
IntroductionCassandraCouchDBDynamoDBMongoDBMySQLPostgreSQLSQLite
IntroductionDartElixirGoJava and JVMMeteorNode.jsPHPPythonRubyRust
IntroductionBeanstalkdRabbitMQRedis
IntroductionElasticsearchMemcachedSphinx
IntroductionCloudBees CodeShip Pro introduction guideCloudBees CodeShip Pro introduction guide 2CloudBees CodeShip Pro introduction guide 3CloudBees CodeShip Pro introduction guide 4CloudBees CodeShip Pro introduction guide 5
Migrating to CloudBees CodeShip Pro
Docker for CI/CD
Getting started with CloudBees CodeShip Pro overview and resources
IntroductionServices configSteps configEnvironment variablesImage registriesImage cachingBuild argumentsVolumesHandling secretsMultiple reposServices and databasesSetting an SSH private keyPreinstalled images
IntroductionInstallationUsing the Jet CLIjet cleanupjet decryptjet encryptjet generatejet loadjet runjet stepsjet updatejet validatejet version
IntroductionAWSAWS S3AWS EBAWS ECSAWS EKSAWS CodeDeployAzure Container ServiceHerokuGoogle CloudGoogle App EngineGoogle Cloud FunctionsGoogle Container EngineGoogle Compute EngineKubernetesTerraformDeploy Via SSHDocker SwarmIBM Cloud FoundryIBM Cloud Container Service
IntroductionBrowser testingParallel testing
IntroductionElixirGoJava and JVMNode.jsPHPPythonRuby
IntroductionCaching multi-stage DockerfileContainer is slow to exitDiffering results with Jet CLIDocker Hub rate limitingManaging multiple environments for a serviceReducing log output from dependent containersStep log not appearingUsing env vars in command steps

Dart

2 minute read

Versions and setup

Dart is not installed on the build VMs by default, but it can be easily added by including these steps in your Setup Commands:

wget -qO- https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo gpg --dearmor -o /usr/share/keyrings/dart.gpg

echo 'deb [signed-by=/usr/share/keyrings/dart.gpg arch=amd64] https://storage.googleapis.com/download.dartlang.org/linux/debian stable main' | sudo tee /etc/apt/sources.list.d/dart_stable.list

sudo apt-get update

sudo apt-get install -y dart
▼

You can use these commands from the Dart SDK:

  • Dart-to-JavaScript compiler (dart2js)

  • Dart VM (dart)

  • Dart package manager (pub)

  • Dart Analyzer (dart_analyzer)

Dependencies

You can install any dependencies you defined in your pubspec.yaml by running

pub get
▼

Dependency Cache

We do not cache Dart dependencies between builds by default, but any dependencies moved into the $HOME/cache directory before the end of the build will be cached and can be retrieved from that directory on the next build.

Frameworks And Testing

As dart currently doesn’t have a default way to run your tests you can use exactly the same command to run those tests as you would on your local machine. Note that almost all tools for custom machine configuration will install and run without issue on CodeShip.

Browser Testing

We automatically have xvfb running on our System. You can use Firefox, Chrome or PhantomJS to run your Dart tests in a browser. You can read more in our Browser Testing Guide

Parallel Testing

If you are running parallel test pipelines, you will want separate your tests into groups and call a group specifically in each pipeline. For instance:

Pipeline 1:

pub run test tests/tests_1.dart
▼

Pipeline 2:

pub run test tests/tests_2.dart
▼

Parallelization Modules

In addition to parallelizing your tests explicitly via parallel pipelines, some customers have found using Dart test runner’s built-in test parallelization is a good way to speed up your tests.

Note that aggressive parallelization can cause resource and build failure issues, as well.

Notes And Known Issues

Due to Dart version and build issues, you may find it helpful to tests your commands with different versions via an SSH debug session if tests are running differently on CodeShip compared to your local machine.

Introduction
Elixir