## Release Notes In this milestone, we added the ability to use the `release-cli` with a `PRIVATE-TOKEN` as defined in [Create a release](https://docs.gitlab.com/ee/api/releases/#create-a-release) API documentation. This enables overriding the user that creates a release to support automation by allowing connection of a project level `PRIVATE-TOKEN` or using a bot user account's `PRIVATE-TOKEN`. ## Further details The following discussion from !5 should be addressed: - [ ] @sean_carroll started a [discussion](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/5#note_290103356): (+1 comment) > @jaime in this case would we be passing `PRIVATE-TOKEN` via the command line? ## Support using the `release-cli` outside of the GitLab CI environment In #9 we decided that the `release-cli` will support creating releases using the `JOB-TOKEN` read from `CI_JOB_TOKEN` (see [CI Environment Variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#overview)). This means that the CLI can only be used inside GitLab's CI environment. We should allow users to use the `release-cli` with a `PRIVATE-TOKEN` as defined in [Create a release](https://docs.gitlab.com/ee/api/releases/#create-a-release) API documentation. ## Options Some options are 1. [x] separate the `-token` option into `-job-token` and `-private-token` (would break compatibility if !6 gets merged first) or 1. [-] add a boolean option like `-ci`, when set then let the code decide if we set `PRIVATE-TOKEN` or `JOB-TOKEN`. So if `-ci=true` default token value to `CI_JOB_TOKEN` read from the env vars ## Implementation - Add support for `-private-token` !32