Added an ngc-publish stage to trigger the NGC Automation scripts for publishing #1249
Conversation
JunAr7112
force-pushed
the
setup_ngc_migration_pipeline
branch
from
880c5e1 to
9df7db0
Compare
.common-ci.yml
Outdated
| # We ensure that the OUT_IMAGE_VERSION and OUT_IMAGE_NAME are set | ||
| - 'echo "Version: ${OUT_IMAGE_VERSION}, Image: ${OUT_IMAGE_NAME}" ; [[ -n "${OUT_IMAGE_VERSION}" && -n "${OUT_IMAGE_NAME}" ]] || exit 1' |
There was a problem hiding this comment.
nit: I think repeating the two checks across two separate lines is simpler and more robust.
There was a problem hiding this comment.
Alright, I switched to two separate lines.
.common-ci.yml
Outdated
| - if: $CI_COMMIT_TAG | ||
| variables: | ||
| PROJECT_NAME: "k8s-device-plugin" | ||
| SOURCE_VERSION: "${CI_COMMIT_TAG}" |
There was a problem hiding this comment.
Question: In discussions with @tariq1890 yesterday, I think we settled on using the short-SHA as the SOURCE_VERSION and the CI_COMMIT_TAG as teh output version.
Also, instead of maintaining the mapping of PROJECT_NAME to full image name in dl/container-dev/ngc-automation, does it makes sense to also pass: NGC_REGISTRY_STAGING_IMAGE_NAME ?
There was a problem hiding this comment.
Hi Evan, I updated the SOURCE_VERSION to CI_COMMIT_SHORT_SHA. Added a TARGET_VERSION with CI_COMMIT_TAG.
On the PROJECT_NAME, in ngc-automation I don't directly map the PROJECT_NAME to the full image name (ie nvcr.io/nvstaging/cloud-native/k8s-device-plugin), instead I map it to a project specific yaml file k8s-device-plugin.yaml which is pushed to the NGC repo for publishing. So I don't think I will need to directly pass NGC_REGISTRY_STAGING_IMAGE_NAME.
.common-ci.yml
Outdated
| # Triggers the downstream container-dev/ngc-automation pipeline to publish the image to NGC | ||
| # This stage is triggered specifically on tags | ||
| trigger-downstream-publishing-pipeline: | ||
| stage: ngc-publish |
There was a problem hiding this comment.
I can add an explicit needs entry on release:staging-ubi9. Right now, I just list the ngc-publish stage to run after release. Also see this discussion
.common-ci.yml
Outdated
| @@ -29,6 +29,7 @@ stages: | |||
| - scan | |||
| - release | |||
| - sign | |||
| - ngc-publish | |||
There was a problem hiding this comment.
Do we need a new stage, or can we reuse the release stage?
There was a problem hiding this comment.
Hi Evan, initially Chris and I were planning for a separate ngc-publish stage to trigger the ngc-automation repo. But I could instead reuse the release stage and include a needs entry on release:staging-ubi9 to ensure the job executes after the image is staged in nvstaging. Would that format work better?
There was a problem hiding this comment.
Following up on this discussion, I added an explicit needs entry on release:staging-ubi9. I don't think we need an explicit ngc-publish stage, so I am fine running trigger-downstream-publishing-pipeline as part of the release stage.
JunAr7112
force-pushed
the
setup_ngc_migration_pipeline
branch
5 times, most recently
from
e24c81d to
4113125
Compare
…ublishing Signed-off-by: Arjun <[email protected]>
JunAr7112
force-pushed
the
setup_ngc_migration_pipeline
branch
from
4113125 to
31350cc
Compare
| PROJECT_NAME: "k8s-device-plugin" | ||
| SOURCE_VERSION: "${CI_COMMIT_SHORT_SHA}" | ||
| TARGET_VERSION: "${CI_COMMIT_TAG}" | ||
| IMAGE_DIST_LIST: ",${DIST}" |
There was a problem hiding this comment.
Probably out of scope for this PR, but why is there a comma here?
This MR adds an ngc-publish stage to trigger the NGC Automation scripts as part of the publishing workflow. The NGC Automation scripts will raise an MR against the NGC configs repo for publishing per the new NGC requirements. The pipeline workflow was tested here.