cisco/elsy

An opinionated, multi-language, build tool based on Docker and Docker Compose

elsy's Issues

lc teardown not removing user-defined networks

Version:

lc --version
lc version 1.2.1 (build: 1173ec7614975ce4666463731204b63b3f6095c3)

Given the following lc.yml:

project_name: sample

and docker-compose.yml:

version: '2'
services:
  blackbox-test:
    image: alpine
    command: /bin/true

Running lc ci will create the following network:

$ docker network ls
5d21e2e46f96        sample_default         bridge

It is expected that lc teardown would remove this network, but it does not. This is bad because if a user tries to later edit the ipam config for the network it will not be applied since the network is already created.

Elsy should attach provenance metadata to docker image

Sometimes it is super hard to track how an image was created (i.e., git-commit, build-number). We should be attaching this provenance metadata to the image before we publish it.

One thought would be to add this using the --label arg to docker build, during the lc package phase, but this will only work for Docker 1.11 and higher.

Custom Maven arguments when using `lc ci`

We frequently find that maven-based projects fail on Jenkins, because mvn's download optimizier decides not to check for new libraries. We've taken to manually adding lc mvn -- --update-snapshots compile (or something similar) at the front of the Jenkins job. Very annoying.

a) It would be nice if a) package/test etc commands could know the were running as lc-ci.
b) the maven template were capable of adding the --update-snapshot to the first mvn invocation.

emberjs-ui Example Tests Fail

The emberjs-ui tests are failing (again), this issue is a place holder to re-enable them in the build (or just remove them because the flake is strong).

Detect git branch that clashes with version in `lc release`

If you execute lc release --version=vx.y.z --git-commit=...., it's guaranteed to fail if you have a local branch called vx.y.z. But the failure message is not helpful. Would be nice if lc would check for this, and provide a helpful error message.

Need a Lifecycle Phase for security-scans

The use of security-scanning in the CD pipeline is getting more and more popular so we should add a lifecycle phase to lc ci called security-scan that will run the security-scan service if it is found.

emberjs-u example has failing unit test

Something must have changed in one of the underlying js dependencies (which are not pinned to an exact version):

Seen with lc version v1.7.0 (build: 06ead918458493f8731f0d30a3d7830ebc665301)

lc --version
lc version v1.7.0 (build: 06ead918458493f8731f0d30a3d7830ebc665301)

cd examples/emberjs-ui/
lc teardown -f
lc ci

... 

## eventually fails on 'test' phase with:
not ok 7 PhantomJS 2.1 - Integration | Component | note list: it renders
    ---
        actual: >
            Add Note
        expected: >

        stack: >
            http://localhost:7357/assets/tests.js:226:17
            wrapper@http://localhost:7357/assets/test-support.js:7132:34
            runTest@http://localhost:7357/assets/test-support.js:3112:32
            run@http://localhost:7357/assets/test-support.js:3097:11
            http://localhost:7357/assets/test-support.js:3239:14
            process@http://localhost:7357/assets/test-support.js:2898:24
            begin@http://localhost:7357/assets/test-support.js:2880:9
            http://localhost:7357/assets/test-support.js:2940:9
        Log: |
    ...

`lc` should abort if `lc.yml` is not present, or if `project_name` is not properly defined

Currently, if there is no lc.yml present, lc will continue working. It should stop dead in its tracks.

Also, project_name needs to be defined, either through lc.yml, or from the command line. Not having it screws up docker network creation between local and Jenkins.

It is possible to release a commit hash that has not been merged into master (or some other suitable branch).

It would be good to fail lc release if the hash is not on a "releasable branch"

Update project name

Looks like it is still set to projectlifecycle in some places: https://github.com/cisco/elsy/search?utf8=%E2%9C%93&q=projectlifecycle

Should Label Docker Images with Git Origin Server if Env Var is Available

Similar to #6 , but we need the git origin server to easily de-reference the git sha.

Make Templates Pluggable

We currently bake templates into the binary and only allow users to customize the docker image via lc.yml (other things can be customized through docker-compose chaining and overriding, but it is not a great user experience).

Instead we should provide users with the ability to easily introduce new templates that are curated by their organization.

`lc blackbox-test` should destroy all the containers it started, unless `--keep-containers` is specified

Many users get tripped up by the fact that running lc blackbox-test leaves the containers it started running after the test finishes (whether passing or not). This is a breaking change that would do two things:

1. change lc blackbox-test to default to killing all containers that it started
2. add a new --keep-containers option to blackbox-test that would mimic the current behavior.

Bootstrap Fails if docker-compose.yml Only Contain Services with Repo's Image

Given an lc.yml with:

name: testbootstrap
docker_image_name: bazzer

And a docker-compose.yml with:

prodserver:
  image: bazzer

Then I would expect lc bootstrap to succeed and not pull any images. However it fails with ERROR: for prodserver pull access denied for bazzer, repository does not exist or may require 'docker login'.

lc upgrade

Proposal for new command lc upgrade that updates lc to latest released version

`package` should support passing docker `--build-arg=[]`

Add docs on what versions of docker and docker-compose elsy supports

We should publish a support matrix for both docker and docker-compose versions.

To support this we also need to test each docker/compose version pair in the matrix, the tasks involved in enabling this are:

• Update TravisCI build to run parallel builds across the different versions
• Figure out how to tag specific features/scenarios of the blackbox-tests if they only work starting at a given docker/compose version; so a build that runs with an earlier version can skip the feature/scenario without failing the build.

Elsy Templates Incompatible with Docker-Compose File Format 2.1 and Beyond

We support the v2 docker-compose file format, but when you try to use anything beyond that (e.g., 2.1) in your repo lc bootstrap will fail with:

ERROR: Version mismatch: file /<somepath>/lc_docker_compose_template155327358 specifies version 2.0 but extension file ./docker-compose.yml uses version 2.1

This is because we hardcode version "2.0" in the template definitions, and then are not smart about dealing with minor versions. Example: https://github.com/cisco/elsy/blob/master/template/mvn.go#L79.

Docker-compose format version support

It would be great to have support for minor version of the docker-compose template format, specifically 2.1 to get HEALTHCHECK / condition: service_healthy facilities which are very useful in general and even more when dealing witch services with warmup condition and/or post-start configs.

Support docker-compose v2 file format for templates

We currently only support the compose v2 file format for repos not using a built-in template (see d6b9310). This is because our templates are hardcoded into the v1 syntax and the way we are using compose file chaining does not work across files with different versions.

I propose the following:

1. Copy the existing template files into an equivalent set of v2 templates.
2. Update the elsy startup code to inspect the repo's compose file. If it is a v1 file, log a deprecation warning and then continue with the current code path. If it is a v2 file chain it using our v2 templates.

This gives us a clean deprecation path for the v1 templates without breaking backwards compatibility for current users.

Make it simpler to override a template image

The current method for overriding templates is a bit cumbersome. It would be nice to add a field to lc.yml that allows a user to specify the template image they want to use for that repo.

publish command broken in docker 1.12

The -f flag to docker tag was finally removed in Docker 1.12: moby/moby#23090. (It has been deprecated since Docker 1.10)

The publish command is broken in Docker 1.12 until this is fixed: https://github.com/cisco/elsy/blob/master/command/publish.go#L100

Use docker-compose pull --parallel flag

compose added a --parallel flag in 1.12.0[1], we should start using that to speed up builds.

The question is, do we need to maintain backwards compatibility with pre 1.12.0 users. I'm thinking no, we just release this as a breaking change.

[1] https://github.com/docker/compose/releases/tag/1.12.0

replace calls to docker-compose with compose-go lib

https://github.com/compose-spec/compose-go

`lc ci` should not report an error if no publish service defined

If you run lc ci on a dev machine, and no publish service is defined, you will see

INFO[0002] Running publish
ERRO[0003] The publish task requires that either a git branch or git tag be set, found neither
ERRO[0003] command failed. use --debug to see full stacktrace

and $? is 1. This makes it look like there's a problem, when there isn't.

I suggest we report the non-existence of a publish service or the fact that publish isn't going to run because there's no GIT_TAG env var as an INFO level message.

Build Breaks with Go 1.11

With golang:1.11 the build is breaking during lc test with:

$ lc test
go test ./command ./helpers ./main ./template
# github.com/cisco/elsy/helpers
helpers/docker-compose.go:175: Debug call has possible formatting directive %q
helpers/docker.go:274: Debugf call needs 1 arg but has 2 args
ok  	github.com/cisco/elsy/command	0.013s
FAIL	github.com/cisco/elsy/helpers [build failed]
ok  	github.com/cisco/elsy/main	0.012s
ok  	github.com/cisco/elsy/template	0.006s
ERRO[0010] exit status 2
ERRO[0010] command failed. use --debug to see full stacktrace
exit status 2

golang:1.11 sha at time of writing this:

$ docker pull golang:1.11
1.11: Pulling from library/golang
Digest: sha256:4400859267b8837d7d94d4cf0c85562984ab5159d75413c23eb2f60caac0d4e4
Status: Downloaded newer image for golang:1.11

`lc ci` should dump logs of all services before tearing them down

When lc ci gets run on a jenkins job, sometimes a build failure is hard to debug since teardown is called after ci finishes[1]. Ideally we should support dumping logs from all services in the docker-compose namespace of the repo before tearing down.

[1] https://github.com/cisco/elsy/blob/master/command/ci.go#L27

Provide short options for long options

Example: -k for --keep-containers.

lc bootstrap no longer hiding confusing log messages for docker versions > 1.12.6

When running lc bootstrap on repos using newer versions of docker versions > 1.12.6 you will see these confusing log messages again, because docker changed their log format...again.

404 Client Error: Not Found ("repository <repo-image-name> not found: does not exist or no pull access")

I've confirmed the above on 17.06.2-ce, but I think this applies to 1.13.x too.

Proposal: remove features

After seeing how elsy has been used for a couple of years now, I think we should simplify it.

• remove templates. They are hidden and feel like magic. Also hard to maintain WRT the docker-composeversion declaration
• remove self-updating. This is brittle and unused. This task should be handled by a package manager. If anything, we should replace it with a system that occasionally reminds the user if a new version is available.
• remove project-name option. We should promote using the standard COMPOSE_PROJECT_NAME env var.

I would like to bundle these changes into the next major version.

blackbox-test command calls package but does not apply image labels

RunPackage relies on the git-commit arg: https://github.com/paulcichonski/elsy/blob/master/command/package.go#L95

However this is only supplied from ci and package, so when lc blackbox-test is run on its lonesome it delegates to package, but no labels get applied.

Server start command does not show server ports on "Docker for Mac"

lc server start [-prod] will normally print out something like the following when run with Docker Toolbox:

INFO[0000] starting service "prodserver"
INFO[0004] Server is running using "prodserver" service
INFO[0035] 8080/tcp is available at 172.17.8.101:32769

Where the 172.17.8.101 address comes from whatever is set for DOCKER_HOST. However DOCKER_HOST is something that is Docker Toolbox specific and Docker for Mac explicitly tells users to unset it because it is not used[1]. This breaks the showing of the IP:PORT when running Docker for Mac, the output is just:

INFO[0000] starting service "prodserver"
INFO[0004] Server is running using "prodserver" service

Need to come up with a smarter way of determining IP[2], since on Docker for Mac it is localhost of the mac.

[1] https://docs.docker.com/docker-for-mac/docker-toolbox/#/setting-up-to-run-docker-for-mac
[2] how we currently do it:

elsy/helpers/docker.go

Line 193 in 91556a4

func DockerIp() (string, error) {

`lc ci` should call `lc clean` before it starts

In order to ensue that there are no stray artifacts in the CI build directories from a previous build, CmdClean should run before any other work begins.

lc release should provide more useful error messages

Users have reported that if there is a branch with the same name as the new release, the error message provided by lc is not useful:

 lc release --git-commit=318642000e12833daccc8a2ddc17dbb45363f2c8 --version=v2.0.2
INFO[0000] creating, and pushing, git tag v2.0.2 at commit 318642000e12833daccc8a2ddc17dbb45363f2c8
error: src refspec v2.0.2 matches more than one.
error: failed to push some refs to 'ssh://[email protected]/ser/svc-sw-flow-sensor-agent.git'
ERRO[0000] exit status 1
ERRO[0000] command failed. use --debug to see full stacktrace

Use Public SBT Image in SBT Template

Our current built-in sbt template uses a non-existent image[1], which is an artifact from pre-opensourcing this project. Currently we mitigate this with docs telling users to override the default image[2], but we really need to update the sbt template to use a publicly available image.

Unfortunately there is no official sbt image so we will need to publish one.

[1] https://github.com/cisco/elsy/blob/master/template/sbt.go#L16
[2] https://github.com/cisco/elsy/blob/master/docs/templates.md#sbt

Update source files with license info

According to the APPENDIX: How to apply the Apache License to your work section of the LICENSE file, we need to put a header in each source file, with the text in that section.

sporadic memory errors during 'lc package'

This happens very infrequently (maybe 1 out of 100 times), lc package will throw the following error:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x514c05]

goroutine 1 [running]:
panic(0x8c0fe0, 0xc8200120d0)
    /usr/local/go/src/runtime/panic.go:481 +0x3e6
stash0.eng.lancope.local/dev-infrastructure/project-lifecycle/helpers.RemoveContainersOfImage(0xc82026c848, 0x7, 0x0, 0x0)
    /go/src/stash0.eng.lancope.local/dev-infrastructure/project-lifecycle/helpers/docker.go:89 +0x735
stash0.eng.lancope.local/dev-infrastructure/project-lifecycle/command.RunPackage(0xc8201fe000, 0x0, 0x0)
    /go/src/stash0.eng.lancope.local/dev-infrastructure/project-lifecycle/command/package.go:62 +0x796

Guessing this related to 82c30e4 and/or c054cde, we should probably just revert that logic since it doesn't work in all cases (i.e., large docker compose files).

lc release false positive error on branch name

Seen on lc version v1.6.1 (build: bb7a94e4e4ad7e8c35dafd2f51a9e1edb6d65386)

Tried:

lc release --version=v5.1.0 --git-commit=27bbb0c6a72

Expected this to work as there was no branch or tag pre-existing with this name, but got:

There is already a branch with the name v5.1.0

It seems to have triggered that error on a branch that simply contained the v5.1.0 fragment, but did not match it exactly:

git branch -a | grep "v5.1.0"
* release-v5.1.0
 remotes/origin/release-v5.1.0

Needs a CI build

We need a functioning CI build that will gate PRs and publish binaries for releases.