Skip to content

Support direct asset links in release-cli

Problem to Solve

Define the filepath when you are creating the asset link. Right now it just creates an asset with an external link and not a direct access to it.

"Release job":
  stage: Release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  before_script:
    - apk --no-cache add openssl ca-certificates
    - mkdir -p /usr/local/share/ca-certificates/extra
    - openssl s_client -connect ${CI_SERVER_HOST}:${CI_SERVER_PORT} -servername ${CI_SERVER_HOST} -showcerts </dev/null 2>/dev/null | sed -e '/-----BEGIN/,/-----END/!d' | tee "/usr/local/share/ca-certificates/${CI_SERVER_HOST}.crt" >/dev/null
    - update-ca-certificates
  script:
    - >
      release-cli create --name "Release $CI_COMMIT_TAG" --description "Created using the release-cli"
      --tag-name $CI_COMMIT_TAG --ref $CI_COMMIT_TAG
      --assets-link='{"name": "Asset1", "url":"https://<domain>/some/location/1", "type": "other", "filepath": "xzy" }'
  rules:
    - if: $CI_COMMIT_TAG

Proposal

Support assets:links:filepath and assets:links:link_type by adding the flag --assets-links-filepath and --assets-links-type --assets-link='{"name": "Asset1", "url":"https://<domain>/some/location/1", "type": "other", "filepath": "xzy" }' and pass to the API for validation.

EDIT: Validating --assets-links-filepath and --assets-links-type in conjunction with --assets-links-name and --asets-links-url poses its own challenges (#48 (comment 398524715)). It was decided to instead use --assets-link that takes a JSON string as parameter (see #48 (comment 398533269))

Implementation

  1. Support sending asset link file path and link type to the API !48 (merged)
  2. Add flag --assets-link='{"name": "Asset1", "url":"https://<domain>/some/location/1", "type": "other", "filepath": "xzy" }' !49 (merged)
  3. Add example usage to the release-cli documentation !50 (merged)
Edited by Jaime Martinez