This repository has been archived by the owner on Apr 20, 2022. It is now read-only.
latest prod tag could change while pipeline is running #125
Comments
marcingrzejszczak
added a commit
that referenced
this issue
Dec 9, 2017
- Change the CF way of doing prod deployment; fixes #111 - Add switch to delete services in CF (deletes everything for a test space); fixes #112 - Refactor the prod deployment function names; fixes #113 - Allow to reuse existing services for test environment via useExisting; fixes #114 - Separate repo with binaries URL for upload and download; fixes #115 - Allow passing of credentials to upload to repo with binaries; fixes #116 - Parametrize the manifest.yml filename; fixes #117 - Rollback smoke test run the latest tests and not the old ones; fixes #118 - Utilize the keyval resource in the concourse pipeline; fixes #120 - Don't log any URLs cause it can contain the password; fixes #121 - Allow multiple ports for stub runner on CF; fixes #123 - Get last prod-tagged release for back-compatibility and rollback jobs; fixes #124 - latest prod tag could change while pipeline is running; fixes #125 - For CF, PAAS_TEST_SPACE should be PAAS_TEST_SPACE_PREFIX; fixes #126 - Added parametrization of sc-pipelines.yml file in pipelines; fixes #127 - Enabled tag deletion in prod-rollback job; fixes #128 - App manifest is ignored; fixes #129 - Update the docs with step by step to convert your project; fixes #30
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If multiple jobs in the pipeline run concurrently, it is possible for apicompatibility and rollback jobs to run against a version of the prod artifact that is older than the one running when the new version reaches the prod-deploy job. Or, if a prod-rollback occurred while a version is being tested or deployed in stage, the apicompatibility and rollback tests become irrelevant and there is no guarantee of back compatibility with current (post-rollback) prod version.
The following update would prevent this:
get latest prod tag in build-api-compatibility-check job, and pass that value to subsequent jobs so that test-rollback-deploy and test-rollback-smoke use the same prod version. Then, pass the value to prod-deploy so that prod-deploy can fail if the running version is different. You would be forced to rerun the pipeline to resolve the problem, which is good.
The text was updated successfully, but these errors were encountered: