jobs:release config release features are not enabled: release

Documentation for release: https://docs.gitlab.com/ee/ci/yaml/#release

It seems like !19298 (merged) added release field in gitlab-ci.yml, but the example configuration cant pass the "CI Lint" with an error message "jobs:release configrelease features are not enabled: release".

My yml:

image: golang:1.13

cache:
  paths:
    - /go/pkg

stages:
  - release


release:
  stage: release
  only: tags
  script:
    - make changelog | tee release_changelog.txt
  release:
    name: Release $CI_TAG_NAME
    tag_name: v0.06
    description: ./release_changelog.txt
    assets:
      links:
        - name: cool-app.zip
          url: http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.zip
        - name: cool-app.exe
          url: http://my.awesome.download.site/1.0-$CI_COMMIT_SHORT_SHA.exe

Notes

Feature introduced in GitLab %13.2 and is now generally available on gitlab.com.

For self-managed instances, GitLab 13.2 and GitLab runner v13.2.0 are required.

mentioned in issue gitlab-org/quality/triage-reports#11 (closed)

added devopsrelease [DEPRECATED] + 1 deleted label

added typebug label

added severity2 label

I'm facing the same issue. Any updates already??
YML:

image: node:latest

stages:
  - build
  - test
  - release

cache:
  paths:
    - node_modules/

install_dependencies:
  stage: build
  script:
    - npm install
  artifacts:
    paths:
      - node_modules/

npm_testing:
  stage: test
  script: npm test
  
release:
  stage: release
  only: tags
  script:
    - make changelog | tee release_changelog.txt
  release:
    name: Release $CI_TAG_NAME
    description: ./release_changelog.txt

mentioned in issue #208610 (closed)

mentioned in issue #208634 (closed)

changed milestone to %Backlog

added needs weight label

@sean_carroll - I think this bug might be related to the fact we haven't completed the runner work, is that right?

If so, I will go on ahead and close.

added priority4 severity4 labels

removed severity2 label

added Category:Release Orchestration label

@jmeshell that is correct, this is currently disabled behind a feature flag until it is fully released.

removed milestone

closed

removed needs weight label

I have the same issue now, is this still not enabled? If this is not enabled maybe it should be noted in documentation?

I might have missed this notice in docs though...

Right, still behind a feature flag - sorry for the confusion @mateszpak and @fkrauthan-fispan

@jmeshell Any idea on a timeline when this feature might be turned on for gitlab.com? I really like the idea of automatic creating releases out of my CI pipeline and this definitely would make it super simple.

I think 13.2, this release it will make it @fkrauthan-fispan

mentioned in merge request biomedit/sett!3 (merged)

Same here. I assumed its enabled as its documented and with a version remark in the docs. But when trying it I got the feature not enabled error message.

Same mistake here. Currently the documentation assumes that this feature is already implemented.

Can someone post the link to where I can enable that feature?

this feature should work as of today, 13.2. @jaime can you advise on docs anchor?

For now @muuvmuuv - here is the link to the release cli tool that has documentation on use https://gitlab.com/gitlab-org/release-cli/-/blob/master/docs/index.md

Edit: @muuvmuuv - here are the docs https://docs.gitlab.com/ee/ci/yaml/#release

Thanks @jmeshell!

@muuvmuuv please note the docs state this feature was introduced in %13.2

Introduced in GitLab 13.2

You also require the latest gitlab-runner v13.2.0 for self-managed instances.

For reference, the feature flag name is ci_release_generation but it's on by default from %13.2 and it will be removed in #229515 (closed)

Thank you both! I will upgrade our EE and Runner next week and test it.

Keep us posted @muuvmuuv

Forgot to inform you that everything works now! This is a huge time saver for our deployment workflow.

I just wanted to note that it is pretty hard to find any documentation about the releaser. The one in the release-ci repo seems outdated because there is no section about the release property or how to add assets to that release from previous stages.

The one in the release-ci repo seems outdated because there is no section about the release property or how to add assets to that release from previous stages.

What do you mean @muuvmuuv can you please point me to that?

Here https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs. The docs are not explaining how to use the property syntax within a release-cli job:

release:
    name: 'Release $TAG'
    description: Release created for ${MAJOR}_${MINOR}_${REVISION}
    tag_name: v${MAJOR}_${MINOR}_${REVISION}

@jaime - can you help with this?

@muuvmuuv here is a sample of how to use the newly added generic packages to upload assets and relate them to your release https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs#release-assets-as-generic-packages.

Here https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs. The docs are not explaining how to use the property syntax within a release-cli job:

That is because the release-cli is a tool of its own that does not depend on the release keyword inside the YAML. Rather the release keyword requires the release-cli under the hood.

We can update the docs in the release-cli to point to the YAML configuration :)

Thank you @jaime

Thank you, @jaime! Could you assist me a little more how I now use a previously generate artifact from e.g. a build job/step, so that I can link it properly in --assets-link:url? Is there any env var I could use to target Artifacts easier?

Let's say I have this artifact: <gitlab_url>/HEM/ci-test/-/jobs/2136/artifacts/raw/test.txt

How do I translate that into the release-ci workflow. I expect something similar like this:

$GITLAB_REPO/$CI_CURRENT_JOB/artifacts/test.txt

@muuvmuuv no problem! You could try using the predefined environment variables in your CI configuration along with artifacts:reports:dotenv or you could download the latest artifacts for a branch. For example,

build-job:
  script: 
    - echo "generating artifacts..."
    - echo "BUILD_JOB_ID=${CI_JOB_ID}" >> variables.env
  artifacts:
    paths:
      - test1.txt
      - test2.txt
    reports:
      dotenv: variables.env

release-job:
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  needs:
    - job: build-job
      artifacts: true
  variables:
    ASSET_URL_ONE: "${CI_PROJECT_URL}/-/jobs/${BUILD_JOB_ID}/raw/test1.txt" # from dotenv
    ASSET_URL_TWO: "${CI_PROJECT_URL}/-/jobs/artifacts/${CI_COMMIT_BRANCH}/raw/test2.txt?job=build-job" # from latest artifacts
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - |
      release-cli create --name "Release $CI_COMMIT_TAG" --tag-name $CI_COMMIT_TAG \
        --assets-link "{\"name\":\"asset-1\",\"url\":\"${ASSET_URL_ONE}\"}" \
        --assets-link "{\"name\":\"asset-2\",\"url\":\"${ASSET_URL_TWO}\"}"

Note: I haven't verified that this works

Thank you! This works:

ASSET_URL_TEST: "${CI_PROJECT_URL}/-/jobs/artifacts/${CI_COMMIT_REF_NAME}/download?job=build-www"

Which is cool because it points to a build ref like from a version tag. Unfortunately opening the url from the release section results in 404, only after reloading the download starts which is weird.

Using the dotenv approach would make our .gitlab-ci huge because we have 5 assets ^^ and it wouldn't be easy to read.

---

Edit:

This works better:

ASSET_URL_TEST: "${CI_PROJECT_URL}/-/jobs/artifacts/${CI_COMMIT_SHA}/download?job=build-www"

changed the description

marked this issue as related to #229515 (closed)

changed the description

Getting this same issue with a gitlab runner version 13.5.0

$ gitlab-runner --version
Version:      13.5.0
Git revision: ece86343
Git branch:   13-5-stable
GO version:   go1.13.8
Built:        2020-10-20T12:05:22+0000
OS/Arch:      linux/amd64

Using the following release job definition:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  needs:
    - job: publish_job
      artifacts: true
  rules:
    - if: $CI_COMMIT_TAG
      when: never        # Do not run this job when a tag is created manually
    - if: $CI_COMMIT_BRANCH == 'stable'  # Run this job when commits are pushed or merged to the default branch
  script:
    - echo 'Release Job for $TAG'
  release:
    name: 'Release $TAG'
    description: Release created for ${MAJOR}_${MINOR}_${REVISION}
    tag_name: v${MAJOR}_${MINOR}_${REVISION}

Can someone assist? Thanks

I do see the same error in VS Code but not GitLab.

We are running:

GitLab 13.4.3 (6689552c479)
GitLab Shell 13.7.0
GitLab Workhorse v8.46.0
GitLab API v4
GitLab Pages 1.25.0
Ruby 2.6.6p146
Rails 6.0.3.1
PostgreSQL 11.7

thanks @muuvmuuv for confirming!

@samir_patel3456 can you confirm your GitLab version and that you are using a docker executor? Unfortunately, the release-cli is not automatically available for non-docker executors. Also the minimum required GitLab version is 13.2.

@jaime Currently at 13.5 and we are using a docker executor. Thanks!

thanks @samir_patel3456 - I will let @jaime help more on this

@samir_patel3456 that is very odd, @sean_carroll can you assist here?

@samir_patel3456 can you please get the output of the following commands

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

If you don't have access to the instance, can you navigate to your instance's help page, e.g. https://gitlab.com/help and note the version at the top?

---

If the version under /help or from the command output is below 13.2 and if you have access to the Rails console, you could run the following command

Feature.enable(:ci_release_generation)

The feature flag :ci_release_generation was enabled by defualt in 13.2. By running the command above you are making sure that the feature is enabled.

@samir_patel3456 thank you for the yaml.

Would you please post the full yaml which is issuing the error?

In this repo I took your example yaml and built out the rest of the instructions. It did validate, so perhaps there is a problem in one of the other nodes?

Example yaml which is validating.

stages:
  - test
  - build
  - release

publish_job:
  stage: build
  script:
    - echo 'build'

echo_test:
  stage: test
  script:
    - echo 'test'

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  needs:
    - job: publish_job
      artifacts: true
  rules:
    - if: $CI_COMMIT_TAG
      when: never        # Do not run this job when a tag is created manually
    - if: $CI_COMMIT_BRANCH == 'stable'  # Run this job when commits are pushed or merged to the default branch
  script:
    - echo 'Release Job for $TAG'
  release:
    name: 'Release $TAG'
    description: Release created for ${MAJOR}_${MINOR}_${REVISION}
    tag_name: v${MAJOR}_${MINOR}_${REVISION}

Thanks all, looks like the client is using a lower version than 13.2. This can be marked as resolved. Regards

Thanks for the update @samir_patel3456 !