Introduce id field in service selector to be used as shortcut in custom environment variables

[isutton]

Motivation

With the configuration values collection and aggregation solved in #407, this change introduces the id field in backing service selectors to be used as alias while composing custom environment variables.

Solves #396

Changes

#407 has grouped service configuration values in the template context using the following the version, api group, kind and name (for example {{ .v1alpha1.postgresql_baiju_dev.Database.db_testing.status.dbConnection }}).

This change groups service configuration values in the template context using the optional id field declared by the user, allowing the user to write {{ .db_testing.status.dbConnection }} instead.

For further more details refer the CONTRIBUTING.md

[openshift-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[pedjak]

e2e tests/examples demonstrating the usage of the new field should be added along with the code.

[sbose78]

I thought we were skipping this piece since we already had a way to refer to backing services as per #407 - however, it's your call team @redhat-developer/service-binding . I'm good with whatever users and the team feels about this! :)

#407 has grouped service configuration values in the template context using the following the version, api group, kind and name (for example {{ .v1alpha1.postgresql_baiju_dev.Database.db_testing.status.dbConnection }}).
This change groups service configuration values in the template context using the optional id field declared by the user, allowing the user to write {{ .db_testing.status.dbConnection }} instead.

@isutton do you mean, we are supporting both what was introduced in #407 and what is currently being proposed ? I'm good if that's the case, wanted to check.

[isutton]

I thought we were skipping this piece since we already had a way to refer to backing services as per #407 - however, it's your call team @redhat-developer/service-binding . I'm good with whatever users and the team feels about this! :)

#407 has grouped service configuration values in the template context using the following the version, api group, kind and name (for example {{ .v1alpha1.postgresql_baiju_dev.Database.db_testing.status.dbConnection }}).
This change groups service configuration values in the template context using the optional id field declared by the user, allowing the user to write {{ .db_testing.status.dbConnection }} instead.

@isutton do you mean, we are supporting both what was introduced in #407 and what is currently being proposed ? I'm good if that's the case, wanted to check.

@sbose78 indeed, #407 populated the custom environment variable template context with:

• all collected service data in a hierarchy with transformed names, replacing - to _ so the value can be used in templates like {{ .v1alpha1.postgresql_baiju_dev.Database.db_testing.status.dbCredentials.username }};and
• all collected data in a hierarchy with the original names.

#468 allows the user to specify an alias (the id property) to be used in the template context, being used like {{ .db_testing.status.dbCredentials.username }}.

Is this clearer, @sbose78?

[sbose78]

Sounds good, Igor.

[ZhuangYuZY]

What is target spec for "id" in SBR ? Any change that before. A SBR CR example will be very help. Thank you.

[codecov]

Codecov Report

Merging #468 into master will increase coverage by 0.06%.
The diff coverage is 66.39%.

@@            Coverage Diff             @@
##           master     #468      +/-   ##
==========================================
+ Coverage   64.69%   64.75%   +0.06%     
==========================================
  Files          27       27              
  Lines        1807     1816       +9     
==========================================
+ Hits         1169     1176       +7     
- Misses        472      473       +1     
- Partials      166      167       +1     

Impacted Files	Coverage Δ
...r/servicebindingrequest/annotations/annotations.go	0.00% <0.00%> (ø)
...roller/servicebindingrequest/annotations/errors.go	0.00% <0.00%> (ø)
pkg/controller/servicebindingrequest/controller.go	0.00% <0.00%> (ø)
...ontroller/servicebindingrequest/envvars/envvars.go	75.55% <0.00%> (ø)
pkg/controller/servicebindingrequest/watch.go	0.00% <0.00%> (ø)
pkg/controller/servicebindingrequest/common.go	29.41% <30.76%> (ø)
...ller/servicebindingrequest/annotations/resource.go	65.65% <41.37%> (ø)
.../controller/servicebindingrequest/sbrcontroller.go	37.82% <45.45%> (ø)
...ler/servicebindingrequest/annotations/configmap.go	85.71% <50.00%> (ø)
...roller/servicebindingrequest/annotations/secret.go	69.23% <50.00%> (ø)
... and 19 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7aa2af...400df4d. Read the comment docs.

[isutton]

/retest

[isutton]

/retest

[pedjak]

@isutton were you able to understand why e2e job is failing on this branch? I see it failing regularly.

[pedjak]

/retest

[baijum]

/test e2e

[pedjak]

please squash commits and we are good to go

[pedjak]

/lgtm

[isutton]

please squash commits and we are good to go

@pedjak force pushed the squashed commits, needs another LGTM.

[pedjak]

/lgtm

[pedjak]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pedjak

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [pedjak]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sbose78]

@isutton Could you include a sample spec in the PR description?