[Snap] Specify architectures

[mthmulders]

Is your feature request related to a problem? Please describe.
Given that JReleaser might not always produce artifacts for all CPU architectures, it would be great if a JReleaser user could modify the architectures section of the snapcraft.yaml.

This is already possible using custom templates. Is it something to consider exposing through JReleaser?

Describe the solution you'd like
I am not too familiar with JReleaser yet to be sure how it should look like. I could imagine something like this in jreleaser.yml:

distributions:
  my-awesome-app:
    type: NATIVE_IMAGE
    snap:
      active: RELEASE
      base: core
      snap:
        active: RELEASE
        architectures: [ amd64, i386 ]
      remoteBuild: true

The new architectures element would have an array of values. For each of them, JReleaser could add a builds-on and a runs-on section to the generated snapcraft.yml.

I don't think it makes sense for JReleaser-published software to build the snaps on one platform and run them on another, but I'm open for suggestions here as I'm not too familiar yet with Snaps.

Describe alternatives you've considered
An alternative that already exists is the existing approach (modifying the snapcraft.yml template).

Additional context

By default, Snapcraft builds a snap to run on the same architecture as the build environment. This behaviour can be modified with an optional root architectures keyword which is added to a snap's snapcraft.yaml.

The architectures keyword defines a set of both build and run architectures with the following syntax:

architectures:
  - build-on: [<build arch 1>, <build arch 2>]
    run-on: [<run arch 1>, <run arch 2>]

(Taken from Snapcraft - Architectures)

[aalmiray]

Based on the doc ink you posted I think it'd be better if we go with the following model:

architectures:
  - build-on: amd64
    run-on: amd64

  - build-on: i386
    run-on: i386

  - build-on: armhf
    run-on: armhf
    build-error: ignore

That is, architectures is a block that may contain one or mode BuildInstructions. A BuildInstruction has 3 properties:

• buildOn: List
• runOn: List
• failOnError: Boolean

We can't use a simple String and a List as the type as the model is backed by a Java class, thus the following becomes available

architectures:
  # example 1
  - buildOn: [i386]
    runOn: [amd64, i386]

  # example 2
  - buildOn: [amd64]
    runOn: [all]

  # example 3
  - buildOn: [amd64]
  - buildOn: [i386]

  # example 4
  - buildOn: [amd64]
    runOn: [amd64]

  - buildOn: [i386]
    runOn: [i386]

  - buildOn: [armhf]
    runOn: [armhf]
    failOnError: false

[aalmiray]

@mthmulders let me know if this is something you'd like to tackle and I can guide you through the required changes. Given that this is a new model update there are several areas that have to be covered:

• jreleaser-model:
  • add architectures block to Snap. Should be optional.
  • validate the architectures block in SnapValidator. At least buildOn should be defined with non empty value.
• jreleaser-templates:
  • modify all snapcraft.yaml templates to handle the architectures block when present .
• jreleaser-tools:
  • process templates with SnapToolProcessor.
• jreleaser-gradle-plugin:
  • map the Groovy DSL model to the core model.
• jreleaser-maven-plugin:
  • map the Maven DSL model to the core model.

[mthmulders]

Given that I know close to nothing about JReleaser's internals, I feel it's a bit too early to start working on this. Also, I'm not sure this is actually something you want to have - although you've removed the "[idea]" so I guess you do.

I'd prefer to start with a small thing (something like we discussed w.r.t. the templates) and start learning JReleaser a bit better :-)