Consistent resin build/deploy workflow

Product support
1

Use case:

During integration test the following is performed:

  • Navigate to a specific folder containing docker-compose.yml and Dockerfile
  • resin build --deviceType intel-nuc --arch stretch --docker ‘/var/run/docker.sock’
  • resin deploy Software_Development

This works as expected.

When at some point a release manager decide to release the integration test release, one of the following workflows can be performed:

Workflow 1:

  • Navigate to the same folder used for build of the integration test release
  • resin deploy Official_Releases

This flow works, but has some major assumptions. It is assumed that the docker prebuild cached layers must be present and has not been changed. If layer is missing or changed, then the release will not be identical to the one used during integration test.

Workflow 2:

  • Navigate to a unspecified folder
  • resin deploy Official_Releases name_of_the_intergration_test_image

This flow works, but has a blocking issue. The deploy process will use a default compose.yml construct hence the release will not be identical to the one used during integration test.

Proposal:

Workflow 3:

  • Navigate to a unspecified folder
  • resin deploy Official_Releases name_of_the_intergration_test_image --compose path_to_compose_file_used_for_the_intergration_test_release

Is something similar to workflow 3 possible?

It would be ideal to be able to deploy a resin image baed on an existing compose file and a prebuild resin image.

4

Hi @aliasbits, I think what you are trying to do should be already possible, here are some ideas:

workflow examples

In workflow 2:

This flow works, but has a blocking issue. The deploy process will use a default compose.yml construct hence the release will not be identical to the one used during integration test.

Is it because you use a Legacy, Classic, or Essentials application? Or just us a single service in general?

If you use a Microservices, then even when you have a single container, you could package it with your own docker-compose.yml? Then no defaults are created, that should work to create the same outcome?
It would be the same setup to create as a multicontainer application, but only using a single service, and you can explicitly base it on the default docker-compose.yml used.

What do you think?

staged releases

Also, we have “staged releases” feature, where you wouldn’t have 2 apps, but one app, that you push too. You can pin devices to a certain release, and thus the integration test device can e.g. run the latest, while the production devices are on a specific release. When the integration test is passed, then you can repin all the devices you want to the tested release, thus the test and production is exactly the same.

Currently it works through the API and here’s the tooling if you’d like to try it:

It’s coming soon to the dashboard / CLI as well, so it will be more user friendly.

5

Hi imrehg

As of now I am using a “Starter” application with a single service which is setup by use of staged release. I am using resin cli version 7.8.4.

This issue is still the following.

If i build with ‘resin build’ in the folder container the compose and dockerfile i get the following:

containers/application-resin-stretch-systemd$ resin build --deviceType intel-nuc --arch stretch --docker ‘/var/run/docker.sock’
[Info] Compose file detected
[Info] Building for stretch/intel-nuc
[Build] Built 1 service in 0:01
[Build] main-test Image size: 170.62 MB
[Success] Build succeeded!

And the following when the container is deployed:

containers/application-resin-stretch-systemd$ resin deploy Software_Development
[Info] Compose file detected

If I try to deploy the same container using the image reference from the same location i get the following:

containers/application-resin-stretch-systemd$ resin deploy Software_Development application-resin-stretch-systemd_main-test
[Info] Creating default composition with image: application-resin-stretch-systemd_main-test

Note that a default compose file is used which also can be verified on the dashboard of the releases.

If i try the same in another folder i get the following:

containers$ resin deploy Software_Development application-resin-stretch-systemd_main-test
[Info] Creating default composition with image: application-resin-stretch-systemd_main-test

I would assume that resin deploy could detect an existing compose file, unless this needs to be done in another way.