Pipeline ID as variable for building docker images and use in deploy step (OD-1922)
Mitesh opened 2 years ago

Hi,

We have a deploy step is set to auto and some times manual. The docker build need to generate docker image with variable like $image-tag=$branchname+pipelineID). e.g imaga-tag=develop-1. We need to reuse when we manually click the deploy button. We tried various job-variables https://docs.onedev.io/appendix/job-variables but it doesn't remain same for next stage.

commit-hash variable is working for us but that becomes to long value to be remembered as image-tag.

Can you please help us to use some variable like pipeline-ID which remains same for all the jobs in single pipeline and can be reused on subsequent auto or manual deploy stages?

  • Robin Shen commented 2 years ago

    Do you mean you have a job generating a docker image with some unique/short tag, and in subsequent jobs of same pipeline, you want to generate new docker image again, but with same image tag as previous job?

  • Mitesh commented 2 years ago

    For an example, The pipeline has total 2 steps. Job1 and Job2.

    There is docker build command in job1 which builds and push the image with repo-URL gcr.io/test-project:repo-name1 and that job is finished.

    Now, there is a subsequent step job2 which is manual and may be we run it tomorrow or on sunday to release that feature. We execute command kubectl set image gcr.io/test-project:repo-name-1. so we want a variable which takes the exact value of repo-name-1 from Job1 so that we apply only that image which was build in previous step.

    So, the Job2 don't generate any variable. it just need a variable which Job1 used.

    For now, we are using the commit-hash variable but that is too long. e.g. gcr.io/test-project:repo-name-7637fdssc1c37082992f46d26246a1a1a287aa115b

    We want to keep it short as reponame-1, 2 ,3...

  • Mitesh commented 2 years ago

    We have figured it out at some extent by publicising artifacts to next stage. thanks. I'm closing this issue.

  • Mitesh changed state to 'Closed' 2 years ago
    Previous Value Current Value
    Open
    Closed
  • Robin Shen commented 2 years ago

    Yes, artifacts are standard approach to share files or information between two jobs.

issue 1/1
Type
Question
Priority
Major
Assignee
Labels
No labels
Issue Votes (0)
Watchers (2)
Reference
OD-1922
Please wait...
Connection lost or session expired, reload to recover
Page is in error, reload to recover