bumping release is necessary for deployment

[medvedzver]

Hi!

We have uaa and uaa-release projects. Uaa is a submodule of uaa-release. When we have a new version of UAA (on develop branch) we have to bump a submodule (uaa-release) in order to deploy newest code, and this is not currently supported by 'bosh-deploy-with-created-release' task. We had to have another task to manually copy uaa files into uaa-release, and output that for 'bosh-deploy-with-created-release' task to use.

Any plans on implementing the task to also bump submodule when creating the release?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/140101429

The labels on this github issue will be updated when the story is started.

[dsabeti]

Hey @medvedzver, thanks for opening this issue.

I think it could make sense to create a new task, or extend the existing ones, to accommodate this workflow. I'm curious to see what else other teams need as they start to use these tasks, so I'll wait on this for a while to get more input.

[aashah]

The CAPI team has a similar situation in that we make commits to cloud_controller_ng which is a submodule for our capi-release.

The way we solved this problem was to bosh create-release our capi-release from a separate task/job and upload the release on our own. We also created an ops-file to have cf-deployment use the latest version of the release that's been uploaded. We used the bosh-deploy task instead of bosh-deploy-with-created-release.

[dsabeti]

Hey @medvedzver and @aashah.

I'm trying to think how this would be accommodated. The task interface might look like this:

inputs:
- name: bbl-state
- name: cf-deployment
- name: cf-deployment-concourse-tasks
- name: ops-files
- name: release
- name: vars-store

outputs:
- name: updated-vars-store

params:
  BBL_STATE_DIR:
  MANIFEST_FILE: cf-deployment.yml
  OPS_FILES:
  SYSTEM_DOMAIN:
  VARS_STORE_FILE: deployment-vars.yml
  REGENERATE_VARS_STORE: false

# ^^ Existing configuration

  BUMP_SUBMODULE: false
  SUBMODULE_PATH: ~
  SUBMODULE_TARGET_BRANCH: ~

This would be the default, which keep the existing behavior. If you wanted to bump a submodule, you'd update configure your pipeline:

BUMP_SUBMODULE: true
SUBMODULE_PATH: src/uaa
SUBMODULE_TARGET_BRANCH: develop

Before the bosh deploy actually happens, the task would do the equivalent of

pushd $SUBMODULE_PATH
  git co $SUBMODULE_TARGET_BRANCH
popd

Would that cover your use case?

(I realize that this looks like an implementation, but I'm actually trying to discover the desired behavior/interface here.)

[davewalter]

Closing due to inactivity.