Screwdriver: Local build feature

[catto]

There are different of build environments between Screwdriver.cd and users' such as environment variables, templates and commands.
It would be great if users can run their build instantly on their local Mac with a mostly the same environment as Screwdriver.cd's.

For example,

1. A user starts a temporal build via CLI
2. CLI parses screwdriver.yaml and run docker container on user's development environment
   
   
   
   1. Setup meta, sd-cmd inside container which can talk to Screwdriver.
   
   

[tk3fftk]

It will possibly be able to implement in tk3fftk/sdctl: Screwdriver.cd API wrapper CLI like $ sdctl build local

[tk3fftk]

Concourse has one-off build feature. It runs a task which is executed inside a container in Concourse cluster and logs are sent to local environment. And the one-off build only can be shown by direct specification of a build iD from UI.

Pros of this one-off build feature are that we can check cluster specific problems like network issue via cli.
Cons of the feature are that it may be slower than a local build.

References:

• Concourse CI (Rapid Local Iteration)
• Running Tasks - Concourse CI

[yuichi10]

Background

The build environment on screwdriver has difference from a user's local environment.
Such as

• Can use sd-step command
• Can use template in screwdriver.yaml
• Can use metadata
• Guarantee build reproducibillity

Objective

• Able to check a result of builds quickly and easily
• Make it easy to troubleshoot

Use cases

• Check the build works correctly
  
  
  
  1. Do steps work as users thought?
  
  
  2. Are tests passed before make a Pull-Request?
  
  
  3. Do scripts that includes sd-cmd work as users thought?
  
  
• Troubleshoot
  
  
  
  1. The builds work correctly in local environment but do not work on screwdriver
  
  
  2. Check the behavior which differ depends on version(such as templates, sd-cmd)
  
  
  3. Investigate user builds by screwdriver admins
  
  

Design

• A user set user token to sdlocal command
• A user can specify a job defined in screwdriver.yaml and start that job
  
  
  
  • A user can configure meta and secrets
  
  
• The build works on the environment which is specified in screwdriver.yaml
• The container has /opt/sd directory copied from launcher image
• A user can obtain logs and artifacts of the build in local

Example

$ ls
screwdriver.yaml
$ cat screwdriver.yaml
jobs:
  test:
    image: centos7:latest
    steps:
      - echo: echo "test"
$ export SD_LOCAL_TOKEN=<User token>
$ sdlocal build test
echo "test"
test

$ ls 
screwdriver.yaml artifacts

• All steps of test job run in the local container
  
  
  
  • echo step logs are printed on user console
  
  
• The build artifacts are stored in artifacts directory

P.S.

If this design is acceptable, we will start to make sdlocal proposal.

[yuichi10]

@jithine
Would you check above background? We write base function about sdlocal. If it is ok, we will start to make proposal which written in detail.

[jithine]

@yuichi10 background details look's good 👏 Please go ahead with proposal.

One thing I would add is the ability to set ssh-agent from localhost and mount custom paths. Use case is that we have x509 certs and ssh agent with sshca certs available for builds in build cluster. In sdlocal that should be able to use the user's ssh agent and x509 certs. In order to facilitate this ,sdlocal should have ability to skip certain (user configurable with an initial list of steps) init and teardown stets

[yuichi10]

Thank you!
You are right. Able to mount ssh-agent looks useful.
We will add the idea to proposal and we will start to write proposal.

[s-yoshika]

We fixed design for sd-local, so we breakdown the tasks.

TODO:

• [x] log-service
• [x] launcher
• [ ] sd-local
  
  
  
  • [x] build command
  
  
  • [x] build command options
  
  
  • [x] meta, meta-file
  
  
  • [x] env, env-file
  
  
  • [x] artifacts-dir
  
  
  • [x] memory
  
  
  • [x] src-url
  
  
  • [x] config command
  
  

[shaochieh]

i ran into problems with pylint. i could locally install and run it after spinning up a clean ubuntu:16.04 container locally in a ubuntu 16.04 VM. also tested complex provisioning steps locally in another fresh ubntu:16.04 container afterwards it still works as expected. it didn't work in SD. im seeing "import error no module named app" from python while running pylint in SD container. we got workaround by running "pylint-fail-under" wrapper. get the feeling that SD container or docker engine might be different than average one. that hypercontainer?