Hi all, this PR is ready for review now.

Considering we will involve Greenwave to make the decision whether to promote an image or not (as described in @mikeb 's C3I Gating and Promotion Workflows initiative) , the stage of running integration test is removed from the pipeline. Now the pipeline only re-tags the image without running any tests so it should be simple enough.

Manually trigger this pipeline to promote an image without running any tests nor complying a Greenwave decision. This matches C3I phase 3: Promotion between environments may still be manual.

In the future, a separated microservice is need to receive the asynchronized message from Greenwave then triggers this pipeline to finish the promotion. This will be aligned with C3I phase 4 Teams have defined the criteria for promotion between environments, and the tests to determine whether those criteria are met are run automatically on every image change.

@csomh @lholecek @ralph Can you take a look?

s/stage/prod/ on this line.

Oh, hello OpenShift template inside Jenkinsfile inside Openshift template.

Is there a way to refer to an external file instead?

@lholecek Yes we can. Using an inline pod template in Jenkinsfile makes it easier for debugging the pipeline itself. Seems it is time to move to an external file.

Let me update the mistake in README.md first.

@lholecek
After thinking it over and investigation, the following approaches can be used to split those HUGE OpenShift template files:

1. Move inline Jenkinsfile to a separated file, then the BuildConfig refers it through a Git Ref.
   Cons: I have to pass every template parameter to an associated Jenkins job parameter.
2. Move inline pod template to a separated YAML file.
   Cons: This is actually impractical because we need to change the YAML at runtime.
3. I am considering if it possible and good to make a Jenkins Pipline Shared Library (https://jenkins.io/blog/2017/10/02/pipeline-templates-with-shared-libraries/) to share Jenkinsfiles between jobs.
   Cons: Making a shared library for pipelines sounds scary.

@rayson I would say, that option 1 is perfectly fine for now, although on a long run option 3 would be even better. But there is no need to be ideal right now.

One more note I have: would it be possible to have only one template parameter for the tagging in imagestream aspect?

...or: why do you think this is important to be parameterized, instead of just always tagging it?

The practical reason right now is I am currently run =E2=80=9Cstaging=E2=80=
=9D pipelines to
alternate targets from my fork of git repo to avoid breaking anything we
are currently running. The current pipeline jobs in waiverdb-test project
of upshift are not touch any tags or repos of upstream waiverdb.

Hunor Csomort=C3=A1ni pagure@pagure.io=E4=BA=8E2018=E5=B9=B48=E6=9C=8817=
=E6=97=A5 =E5=91=A8=E4=BA=94=E4=B8=8B=E5=8D=8811:37=E5=86=99=E9=81=93=EF=BC=
=9A

csomh commented on the pull-request: CI/CD: Add image promotion pipeline=
that you are following:
``
@rayson I would say, that option 1 is perfectly fine for now, although on
a long run option 3 would be even better. But there is no need to be idea=
l
right now.

One more note I have: would it be possible to have only one template
parameter for the tagging in imagestream aspect?

...or: why do you think this is important to be parameterized, instead of
just always tagging it?
``

To reply, visit the link below or just reply to this email
https://pagure.io/waiverdb/pull-request/223

The current pipeline jobs in waiverdb-test project of upshift are not touch any tags or repos of upstream waiverdb.

Ok, I see.

Updated to use the new pipeline templates and jobs directory layout.

+1 Though this depends on PR#227 (otherwise the *.env/*.tmpl files make no sense).

Note: This PR depends on #227.

@rayson I'm OK with merging this after you resolve the merge conflicts.

@rayson pls rebase :)

Rebased.