## Problem Following release of the [inbound CI_JOB_TOKEN](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html) setting users who automate creation of projects cannot also automate adding the projects allowed to use a CI_JOB_TOKEN with the project. This is possible with the GraphQL endpoints * [Mutation.ciCdSettingsUpdate](https://docs.gitlab.com/ee/api/graphql/reference/#mutationcicdsettingsupdate) * [Mutation.ciJobTokenScopeAddProject](https://docs.gitlab.com/ee/api/graphql/reference/#mutationcijobtokenscopeaddproject) * [Mutation.ciJobTokenScopeRemoveProject](https://docs.gitlab.com/ee/api/graphql/reference/#mutationcijobtokenscoperemoveproject) This is needed because some users prefer to use REST over graphql or use libraries to interact with the api that do not support graphql. ### Proposal | Endpoint to implement | Description | Merge Request | Author | | ------ | ------ | ------ | ------ | | `GET projects/:id/job_token_scope` | Get settings `inbound_enabled` and `outbound_enabled` (no allowlists because it needs pagination) | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117842 | @gerardo-navarro | | `GET projects/:id/job_token_scope/allowlist/:direction` | Get the allowlist of projects (where `direction` is `inbound/outbound`) | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118495 | @gerardo-navarro | | `PATCH projects/:id/job_token_scope` | update params such as `inbound_scope_enabled` and `outbound_scope_enabled` | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118357 | @gerardo-navarro | | `POST projects/:id/job_token_scope/allowlist/:direction?project_id=123` | add a project to the allowlist | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119675 | @gerardo-navarro | | `DELETE projects/:id/job_token_scope/allowlist/:direction?project_id=123` | remove project from the allowlist This does not include the projects that are allowed to access the project though. | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119687 | @dbiryukov | For context, we decided to keep the setting toggle off of project since it should only be set by maintainers and to avoid making the project api responsible for too much. The discussion is here: https://gitlab.com/gitlab-org/gitlab/-/issues/378339 ### Permissions This should only be shown to users with a Maintainer or higher role within the project to match [existing permissions](https://docs.gitlab.com/ee/user/permissions.html#gitlab-cicd-permissions) for CI/CD settings. ### Implementation Guide - GET use `ProjectCiCdSettings` `inbound_job_token_scope_enabled` method or `Project`'s inbound_job_token_scope_enabled` method - Currently, the outbound setting is on project but I think it's ok to keep this inconsistency for now given that we are [retiring that feature entirely](https://gitlab.com/gitlab-org/gitlab/-/issues/383084). - PATCH use `ProjectCiCdSettings` `update` method or `=inbound_job_token_scope_enabled` as delegated through project. - GET use `Ci::JobToken::Scope` - DELETE use `::Ci::JobTokenScope::RemoveProjectService` - POST use `::Ci::JobTokenScope::AddProjectService` targetProject refers to the project to add to the allowlist in the graphql api currently and not the project we are trying to access. <summary> Old Writeup </summary> <details> #### Note 2023-02-23 This was re-written as a feature request as there was not an endpoint exposed for the token previously in the projects API. ### Summary <!-- Summarize the bug encountered concisely. --> Following the documentation for CI/CD Job Access Token Limits, https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-gitlab-cicd-job-token-access I want to enable this setting for all my projects in a group. I have many subgroups and projects, and my goal is to automate this process now and later run the script in a scheduled cronjob to ensure the setting remains enabled for every project. ### Steps to reproduce <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> 1. Create a new project, note the project ID 1. Export GITLAB_TOKEN into the environment, needs at least maintainer permissions 2. Use the API to update the setting following this command ``` # https://gitlab.com/everyonecancontribute/dev/learn-wasm-assemblyscript.git = 37766828 curl --request PUT --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \ --url 'https://gitlab.com/api/v4/projects/37766828' \ --data "ci_job_token_scope_enabled=true" ``` Alternatively, test with a group, export GROUP_ID as environment variable, and download the script from this MR draft: https://gitlab.com/dnsmichi/api-playground/-/merge_requests/12/diffs I wrote the script to update all projects within a group. Requires `pip install python-gitlab` before executing. ### Example Project <!-- If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report. If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version. --> ### What is the current *bug* behavior? <!-- Describe what actually happens. --> Updating the settings throws an error, saying that other attributes are missing in the PUT request. ``` {"error":"allow_merge_on_skipped_pipeline, analytics_access_level, autoclose_referenced_issues, auto_devops_enabled, auto_devops_deploy_strategy, auto_cancel_pending_pipelines, build_git_strategy, build_timeout, builds_access_level, ci_config_path, ci_default_git_depth, ci_allow_fork_pipelines_to_run_in_parent_project, ci_forward_deployment_enabled, ci_separated_caches, container_registry_access_level, container_expiration_policy_attributes, default_branch, description, emails_disabled, forking_access_level, issues_access_level, lfs_enabled, merge_pipelines_enabled, merge_requests_access_level, merge_requests_template, merge_trains_enabled, merge_method, name, only_allow_merge_if_all_discussions_are_resolved, only_allow_merge_if_pipeline_succeeds, operations_access_level, pages_access_level, path, printing_merge_request_link_enabled, public_builds, remove_source_branch_after_merge, repository_access_level, request_access_enabled, resolve_outdated_diff_discussions, restrict_user_defined_variables, security_and_compliance_access_level, squash_option, shared_runners_enabled, snippets_access_level, tag_list, topics, visibility, wiki_access_level, avatar, suggestion_commit_message, merge_commit_template, squash_commit_template, repository_storage, packages_enabled, service_desk_enabled, keep_latest_artifact, mr_default_target_self, enforce_auth_checks_on_uploads, issues_enabled, jobs_enabled, merge_requests_enabled, wiki_enabled, snippets_enabled, container_registry_enabled, approvals_before_merge, external_authorization_classification_label, fallback_approvals_required, import_url, issues_template, merge_requests_template, merge_pipelines_enabled, merge_trains_enabled, requirements_access_level are missing, at least one parameter must be provided"}% ``` ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> Updating the project setting works, and I can automate the security settings for CI/CD Job Token Access Limits. ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. -->  ### Output of checks <!-- If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com --> This bug happens on GitLab.com #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (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`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> Either the field is hidden in the REST API, it is not expected as a PUT/POST body, or it does not exist yet. </details. Maybe related: https://gitlab.com/gitlab-org/gitlab/-/issues/357547 Related issues: - https://gitlab.com/gitlab-org/gitlab/-/issues/370069 - https://gitlab.com/gitlab-org/gitlab/-/issues/335465 - https://gitlab.com/gitlab-org/gitlab/-/issues/340822 - https://gitlab.com/gitlab-org/gitlab/-/issues/342842