Allow advanced filtering of flavors to be built

[alambike]

Use case

Currently, we don't have an option to skip the automatic build of pre-releases when the build_snapshots workflow is triggered, as both elements are classified under the same image_type.

Option 1: The ugly

To skip this limitation, we could easily add support for fnmatch glob patterns,

So we can use it in the build_images workflow automatic invocation, to filter by an agreed pattern:

[!WARNING]
This is not generalizable, what is hardcoded in the workflow cannot be extrapolated to any developer's use case, since it will imply a flavor naming convention.

https://github.com/prefapp/features/blob/main/packages/build_images/templates/.github/workflows/build_snapshots.yaml#L38

jobs:
  call-build:
    if: github.event_name == 'push' || github.event_name == 'workflow_dispatch' || (github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'autodeploy'))
    uses: prefapp/firestarter-workflows/.github/workflows/build_images.yaml@v1
    secrets: inherit
    with:
      type: snapshots
      from: ${{ inputs.from || github.event.pull_request.head.sha || github.sha }}
      flavors: ${{ inputs.flavors || '*-pre' }} # <- here is the catch

Option 2: The good

Instead of try to agree with a flavor naming convention with the developer team, we could use flavor labels, based on the github.event_name and types. For example, to configure the build of my flavor on pre-release events, I have to configure:

snapshots:
  my-flavor-1:
    build_args:
      VITE_API_URL: "https://my-api-url/graphql"
    dockerfile: docker/Dockerfile
    labels: 
       tenant: mytenant1
       trigger_event: release
       trigger_event_action: prereleased

And the build-prereleases workflow will have the following call:

    with:
      type: snapshots
      from: ${{ inputs.from || github.event.pull_request.head.sha || github.sha }}
      flavors: ${{ inputs.flavors || '*' }}
      matchLabels: |
          trigger_event: ${{ github.event_name }}
          trigger_event_action: ${{ github.event.release.action }}

[frmadem]

I don't follow this particula label, the tenant label can not interfere in the building decission right? @alambike

[alambike]

Is an example of extra labels that a flavor could have, to try to show that the matchLabel option should try to find the flavors which match with the labels specified, but other labels can be defined in the flavor configuration.