A new task to generate labels

[ralphbean]

For https://issues.redhat.com/browse/KONFLUX-4274. Turns out people really do use those labels (see linked issues).

This can have a future connection with #1268 once we do that. I.e., use the commit timestamp for the release label and build-date, rather than the real world date. But, that's for another day...

[arewm]

There has been more interest in this type of functionality from users (i.e. to set/forward the git tags so that they can be used at release time). Should we add this to the default pipelines?

@mmorhun , have there been any criteria defined for when to add tasks to the default pipelines?

[samdoran]

I would love the ability to pass in a list of key=value labels to the build tasks. That wolud save some steps compared to what I am doing today.

I'm not as clear on the value of the generate-labels task. It seems limited to set of four values that can be applied to arbitrary keys.

What would provide more utility and flexibility is a task parameter for an executable in the repository that returns a JSON list of key=value pairs.

[arewm]

I'm not as clear on the value of the generate-labels task. It seems limited to set of four values that can be applied to arbitrary keys.

The specific values mentioned are just those that it helps to interpolate. I think that it should be possible to modify this task parameters to add any variables that you want. For example, would something like this work?

   - name: label-templates
     value: 
        - "release=$SOURCE_DATE_EPOCH"
        - "build-date=$SOURCE_DATE"
        - "short-commit=$(tasks.git-clone.results.short-commit)"
   - name: source-date-epoch
     value: '$(tasks.git-clone.results.commit-timestamp)

(well, commit-timestamp might actually provide a pretty date, not an epoch ... )

This task can be used to inject content into labels (from other tasks' results, for example). This does provide some indirection ... but if you don't need any of the label templates then you can also use the new parameter in the buildah task to directly add desired labels without having to use an ARG-based indirection.

[samdoran]

It seems like the ADDITIONAL_LABELS parameter is sufficient for our needs. I don't see an immediate use for the label templates task, but that's just for our projects.

[chmeliik]

What would provide more utility and flexibility is a task parameter for an executable in the repository that returns a JSON list of key=value pairs.

This is tricky, because executing arbitrary code before the build voids the "trust" of the build pipeline.

It would be doable in a trusted-artifacts pipeline - it would have to be a task that takes the source-code artifact as input but doesn't return a source-code artifact as output (any potential modifications would be local-only). And rather than running an executable from the source repo, the task could just execute any arbitrary script passed in (the script would run with the source repo as PWD, so could execute anything in the repo if needed).

Maybe we should just add copy-and-pasteable snippets to the docs showing how to insert custom tasks into a trusted-artifacts pipeline in the least painful way

[ralphbean]

Yeah, perhaps if we ran that arbitrary executable with unshare and no net, that would be acceptable. But, in any case - I think it's out of scope of this change.

[samdoran]

This is tricky, because executing arbitrary code before the build voids the "trust" of the build pipeline. It would be doable in a trusted-artifacts pipeline...

I figured there would be some challenges with running arbitrary code. I'm doing this today in a custom task with a trusted artifact and it meets our needs while not compromising the integrity of the build artifact.

Perhaps this is something best left to individual pipeline authors to implement as needed.

Maybe we should just add copy-and-pasteable snippets to the docs showing how to insert custom tasks into a trusted-artifacts pipeline in the least painful way.

That's probably the best solution. It took me way more time than I would like to admit to get something so "simple" working, especially with the trusted artifacts model.

[arewm]

looks reasonable to me. Thanks.

[chmeliik]

A couple minor improvements, otherwise LGTM

[mmorhun]

It looks complicated.
Could we have additional labels in a dedicated env var for example?

[ralphbean]

I started that way @mmorhun, but if we make the labels available to the script as an env var, then I don't think I can make the param an array.

[mmorhun]

Will a delimiter in the env var work? Like label1=value1|label2=something else

[chmeliik]

Label values are too free-form for delimiters to work

Ralph's original approach was to use a JSON string of an array, but that's much less user-friendly

You can't really make something like this work with a JSON string

params:
  - name: LABELS
    value:
      - $(tasks.generate-labels.results.LABELS[*])
      - foo=bar

[tkdchen]

Indentation issue.

[chmeliik]

I think that's just the TA task generation doing some formatting ¯\_(ツ)_/¯

[chmeliik]

LGTM, please squash into a number of commits that you consider appropriate before merging