Fix the templating of secret variables in github pipelines

[chmeliik]

Adresses the TODOs in the workflow files about using the secrets list from templates/data.yaml

[chmeliik]

It's silly to include this here, so I'll think of some exclusion mechanism (maybe just ignore this one specific secret directly in the template code)

[jduimovich]

It's silly to include this here, so I'll think of some exclusion mechanism (maybe just ignore this one specific secret directly in the template code)

I was thinking we automatically include if the repo is gitlab ... Its kind of a pain to have to uncomment it... We can fix automate in the generated templates
See this https://github.com/redhat-appstudio/tssc-sample-templates/blob/main/skeleton/gitops-template/components/http/overlays/development/source-repository.yaml as an example
In this repo, we have to generate this code in the jenkinsfile for use in the tssc-sample-template ( template generating code to be expanded later(
{%- if values.hostType == 'Gitlab' %}
GITOPS_AUTH_USERNAME: ${{ secrets.GITOPS_AUTH_USERNAME }}
{%- endif %}

[chmeliik]

This is the GH actions pipeline, so the repo is never Gitlab (which is what I meant by "it's silly to include this")

[jduimovich]

This is the GH actions pipeline, so the repo is never Gitlab (which is what I meant by "it's silly to include this")

Agree.
We're talking about a two things.

1. automatically adding the line if the repo the jenkinsfile is in fact a gitlab repo. We can do that at template generation time when we know the destination git type and the user doen't need to undo the commenting out
2. Your point that Github should not have it - the mechanism for that in the generator is fine but the case (1) would take care of it but I agree would look silly

We should do both

[chmeliik]

I noticed that the gitlab-ci pipelines don't set any variables explicitly, how does that work? Do all the org-wide variables just apply implicitly, even without being defined in the YAML?

[simonbaird]

I noticed that the gitlab-ci pipelines don't set any variables explicitly, how does that work? Do all the org-wide variables just apply implicitly, even without being defined in the YAML?

Not sure why it's inconsistent. Maybe the vars are set via the ./rhtap/env.sh file, so there's no need to set them again in the yaml.

[jduimovich]

I noticed that the gitlab-ci pipelines don't set any variables explicitly, how does that work? Do all the org-wide variables just apply implicitly, even without being defined in the YAML?

Yes, gitlab variables are available by default in the pipelines. There are some options to restrict some to protected branches and for PRs and to mask or allow visible values

[jduimovich]

Not sure why this is needed, in Jenkins, when you use credentials QUAY_IO_CREDS = credentials('QUAY_IO_CREDS') it creates the other two.

The code credentials ('VARIABLE_NAME') makes <VARIABLE_NAME>, <VARIABLE_NAME>_USR, <VARIABLE_NAME>_PSW
with VARIABLE_NAME being defined as the colon separated value USR:PSW

[chmeliik]

Not sure why this is needed, in Jenkins, when you use credentials QUAY_IO_CREDS = credentials('QUAY_IO_CREDS') it creates the other two.

The code credentials ('VARIABLE_NAME') makes <VARIABLE_NAME>, <VARIABLE_NAME>_USR, <VARIABLE_NAME>_PSW with VARIABLE_NAME being defined as the colon separated value USR:PSW

In Jenkins yes, in Github no. So we either need to update templates/data.yaml with something like this:

build_secrets:
  - name: QUAY_IO_CREDS
    if: ci == "jenkins"
  - name: QUAY_IO_CREDS_USR
    if: ci != "jenkins"
  - name: QUAY_IO_CREDS_PSW
    if: ci != "jenkins"

Or stop relying on Jenkins-specific behavior

[chmeliik]

In Jenkins yes, in Github no. So we either need to update templates/data.yaml with something like this:

build_secrets:
  - name: QUAY_IO_CREDS
    if: ci == "jenkins"
  - name: QUAY_IO_CREDS_USR
    if: ci != "jenkins"
  - name: QUAY_IO_CREDS_PSW
    if: ci != "jenkins"

I gave this a shot, see if you prefer this

[chmeliik]

Rebased on main, re-generated to include the TRUSTIFICATION secrets