action.yml

name: 'tuplip build and push'
author: 'matfax'
branding:
  icon: 'tag'
  color: 'blue'
description: |
  tuplip enables advanced tagging of Docker images by parsing Docker dependencies and versions into a superset of tags.
inputs:
  sourceTag:
    description: |
      You can pass your own source tag to an existing local image.
      Then, this action will not execute `docker build` before pushing and assume that your workflow has ensured
      that the given tag exists locally, ready to be pushed.
      The local image ideally is provided by another script given in the `buildScript` input.
      This is useful if the docker image needs to be build with advanced parameters,
      or if the image exists already somewhere and only needs to be pulled, ready to be redistributed.
      If no source tag is set, this action will perform the building itself, using the name of the workflow job.
      Set it to any non-zero value to enable the flag (e.g., `build-tag`).
    required: false
    default: ''
  buildScript:
    description: |
      The script given in this input will override the default build mechanism of this action.
      The `sourceTag` of the built image will also have to be provided then.
      The advantage of passing a buildScript is that the build is executed in the same environment as the push.
      That accelerates workflow runtime and makes sure that consistent docker versions are used.
      The script has to be in POSIX standard.
      Set it to any non-zero path to enable the flag (e.g., `./build.sh`).
    required: false
    default: ''
  buildOnly:
    description: |
      This lets tuplip use the `tag` command instead of the `push` command.
      It's very useful for testing workflows that aren't supposed to push anything to Docker (e.g., for pull requests).
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  buildArgs:
    description: |
      This defines a set of additional docker build arguments that are supposed to be passed to the given Dockerfile.
      The arguments only define the list of environment variables that are explicitly passed.
      In order to pass ARG ONE="one" and ARG TWO="two" to the Dockerfile, set `buildArgs` to `
      |
        ONE
        TWO
      `,
      and pass `ONE: 'one'` and `TWO: 'two' as environment variables in the `env` section of the workflow action.
    required: false
    default: ''
  repository:
    description: |
      This defines the public repository path on which the images are to be pushed.
      By default, the same repistory org and name will be used as the repository on that this action is executed.
      This will match if `github.com/gofunky/ignore` pushes on `hub.docker.com/r/gofunky/ignore`, for instance.
      However, if an `ARG REPOSITORY=` is defined in the Dockerfile, for security reasons, this action will only
      proceed if Dockerfile and action input use the same repository as target.
      In order to accept any given `ARG REPOSITORY` from the Dockerfile, set this input to an empty value (i.e., '').
    required: false
    default: ${{ github.repository }}
  path:
    description: |
      This defines the path to the Dockerfile without the name of the Dockerfile itself.
    required: false
    default: '.'
  dockerfile:
    description: |
      This only defines the name of the Dockerfile without its path.
    required: false
    default: 'Dockerfile'
  username:
    description: |
      IMPORTANT: Only use secrets to pass credentials to the action (e.g., secrets.DOCKER_USR)!
      If this input is given, a docker login will be attempted before pushing the tagged images.
      If not given, the login will be skipped. The workflow has to perform the docker login before this action then.
    required: false
    default: ''
  password:
    description: |
      IMPORTANT: Only use secrets to pass credentials to the action (e.g., secrets.DOCKER_PWD)!
      If inputs.username is given, the password (or token) also has to be defined.
    required: false
    default: ''
  excludeMajor:
    description: |
      This adds the `--exclude-major` flag to the push command.
      `--exclude-major` excludes the major versions (e.g., go1 for go:1.2.3) from the considered version variants.
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  excludeMinor:
    description: |
      This adds the `--exclude-minor` flag to the push command.
      `--exclude-minor` excludes the minor versions (e.g., go1.2 for go:1.2.3) from the considered version variants.
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  excludeBase:
    description: |
      This adds the `--exclude-base` flag to the push command.
      `--exclude-base` excludes the base alias (e.g., go for go:1.2.3) from the considered variants.
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  addLatest:
    description: |
      This adds the `--add-latest` flag to the push command.
      `--add-latest` not only pushes the determined tags from the tag vectors but also the `latest` tag.
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  exclusiveLatest:
    description: |
      This adds the `--exclusive-latest` flag to the push command.
      `--exclusive-latest` makes the `latest` root tag vector version an exclusive tag if given.
      This is especially useful for automated builds (e.g., Docker Hub builds) where the root tag vector version is
      passed from the build system.
      In other words, this means that only `latest` will be pushed once `latest` is given as root tag but nothing else,
      so that `latest` builds can remain separated from release builds.
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  rootVersion:
    description: |
      This adds the `--root-version` flag to the push command.
      `--root-version` overrides the root tag vector's version of the given Dockerfile.
      Set it to any non-zero value to enable the flag (e.g. `1.0.0`).
    required: false
    default: ''
  checkSemVer:
    description: |
      This adds the `--check-semver` flag to the push command.
      `--check-semver` lets tuplip verify all versioned tag vectors for a valid semantic version syntax.
      Set it to any non-zero value to enable the flag (e.g. `true`), `false` also counts as true.
    required: false
    default: ''
  straight:
    description: |
      This adds the `--straight` flag to the push command.
      `--straight` lets tuplip use the input tags directly without any mixing.
      Only single-itemed tags will be pushed.
      Since straight tags won't be mixed, they have to provided directly as input.
      The tags from the Dockerfile will be ignored.
      Set it to a comma-separated list of tags to enable the flag (e.g. `some,tag`).
      A line-separated list is accepted as well: `
      |
        some
        tag
      `
    required: false
    default: ''
  filter:
    description: |
      This adds the `--filter` flag to the push command.
      `--filter` excludes all tags without the given set of tag vectors from the output set.
      Only tags will be pushed that represent supersets of the given tags.
      Set it to a comma-separated list of tags (e.g. `some,tag`).
      A line-separated list is accepted as well: `
      |
        some
        tag
      `
    required: false
    default: ''
outputs:
  tags:
    description: 'the list of pushed tags'
runs:
  using: 'docker'
  image: 'Dockerfile'