Push steps data container support

feature_request

#1

Hi all,

We have a push step like this

  - type: serial
    tag: master
    service: production
    type: push
    image_name: "private_repo_name/folder/function_name
    image_tag: "0.0.2-{{.CommitID}}"
    registry: private_registry_name
    encrypted_dockercfg_path: environment/dockercfg.encrypted

This is a nodejs container, and I would like the name and version to be extracted from the package.json. The same would apply to all common build systems.

The idea is to allow push steps to link to data containers, and have a mechanism to populate extra environment variables based on files in the data container.

These are the perceived benefits (in priority order):

  • I don’t need to remember to bump the version in 2 places before I do the release tag.
  • I can create a standard template for Codeship template services and steps files which can be copied into many existing git repos.
  • I can rename the name in package.json without needing to remember to do the same in the codeship-steps.yml file.

I did try image_name: “privatereponame/folder/{{.RepoName}}” to solve the name part of the problem, but you can’t interpolate there apparently.

As an aside, I would also like to push using the abbreviated form of the CommitID. A data container would again be useful there.

When the docker compose v2 support comes along, the same mechanisms could be used to pass in build args.

Am I over-complicating things here?

Does anyone have an example of how to get project metadata out of the build configuration files?


#2

Hi Paul,

I have recorded your request for script-based tags, which is something we don’t currently offer. This is certainly something we would like to provide to our users, though we don’t have an ETA a this moment. When we are able to work on this, I can reach out to you.

Best,
Neda


#3

This is blocking us from using codeship into our whole platform.

We’re coming from gitlab-ci and it supported variables in the whole file, so in codeship we found that we need to keep copying blocks just to change a variable, and we end up with tons of steps instead of just using one that fills up with variable contents - and this is still bad because we can’t make it dynamic as we wanted to.

For example, we have several containers that the build process is almost the same, and we wanted to just make a generic one that uses the CI variables everywhere, so we can automate most stuff.

Current

- type: serial
  steps:
    - name: test development
      service: development
      command: npm run test
      tag: development
    - name: push development
      service: development
      type: push
      image_name: user/proj
      image_tag: "{{.Branch}}"
      registry: https://index.docker.io/v1/
      encrypted_dockercfg_path: codeship-docker.enc
      tag: development

    - name: test staging
      service: staging
      command: npm run test
      tag: release
    - name: push staging
      service: staging
      type: push
      image_name: user/proj
      image_tag: "{{.Branch}}"
      registry: https://index.docker.io/v1/
      encrypted_dockercfg_path: codeship-docker.enc
      tag: release
    
    - name: test production
      service: production
      command: npm run test
      tag: master
    - name: push production
      service: production
      type: push
      image_name: user/proj
      image_tag: "{{.Branch}}"
      registry: https://index.docker.io/v1/
      encrypted_dockercfg_path: codeship-docker.enc
      tag: master

Expected

- type: serial
  steps:
    - name: test
      service: container
      command: npm run test
    - name: push
      service: container
      type: push
      image_name: "{{.RepoName}}
      image_tag: "{{.Branch}}"
      registry: https://index.docker.io/v1/
      encrypted_dockercfg_path: codeship-docker.enc
      tag: (development|release|master)

So it would be amazing to support these templates in the whole file

This also applies to services file. Because we need to keep copying the blocks on services too (for build args and env vars)

So we have 1 container, but defined as 5 different services, which doesn’t make sense.