diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2019-12-20 21:07:53 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2019-12-20 21:07:53 +0300 |
commit | 682360490629376e2ec07d737c7d7dbfdaaeeab7 (patch) | |
tree | 7abe62a4d200738ac086ac0c0bd633ce0bc03f00 /doc | |
parent | 2f26f81ce3e3f97ddc5ce5e2e103925d7d0d170f (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/api/issue_links.md | 8 | ||||
-rw-r--r-- | doc/user/packages/index.md | 6 | ||||
-rw-r--r-- | doc/user/packages/workflows/project_registry.md | 85 |
3 files changed, 98 insertions, 1 deletions
diff --git a/doc/api/issue_links.md b/doc/api/issue_links.md index b7e21310a19..9351b3e4dd5 100644 --- a/doc/api/issue_links.md +++ b/doc/api/issue_links.md @@ -57,7 +57,7 @@ Parameters: Creates a two-way relation between two issues. User must be allowed to update both issues in order to succeed. ``` -POST /projects/:id/issues/:issue_iid/links/:target_project_id/:target_issue_iid +POST /projects/:id/issues/:issue_iid/links ``` | Attribute | Type | Required | Description | @@ -67,6 +67,12 @@ POST /projects/:id/issues/:issue_iid/links/:target_project_id/:target_issue_iid | `target_project_id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) of a target project | | `target_issue_iid` | integer/string | yes | The internal ID of a target project's issue | +```bash +curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/4/issues/1/links?target_project_id=5&target_issue_iid=1" +``` + +Example response: + ```json { "source_issue" : { diff --git a/doc/user/packages/index.md b/doc/user/packages/index.md index 613b4c975f4..dda43390cf1 100644 --- a/doc/user/packages/index.md +++ b/doc/user/packages/index.md @@ -22,3 +22,9 @@ guide you through the process. Or check out how other members of the commmunity are adding support for [PHP](https://gitlab.com/gitlab-org/gitlab/merge_requests/17417) or [Terraform](https://gitlab.com/gitlab-org/gitlab/merge_requests/18834). NOTE: **Note** We are especially interested in adding support for [PyPi](https://gitlab.com/gitlab-org/gitlab/issues/10483), [RubyGems](https://gitlab.com/gitlab-org/gitlab/issues/803), [Debian](https://gitlab.com/gitlab-org/gitlab/issues/5835), and [RPM](https://gitlab.com/gitlab-org/gitlab/issues/5932). + +## Package workflows + +Learning how to use the GitLab Package Registry will help you build your own custom package workflow. + +[Use a project as a package registry](./workflows/project_registry.md) to publish all of your packages to one project. diff --git a/doc/user/packages/workflows/project_registry.md b/doc/user/packages/workflows/project_registry.md new file mode 100644 index 00000000000..57befc4ecb8 --- /dev/null +++ b/doc/user/packages/workflows/project_registry.md @@ -0,0 +1,85 @@ +# Project as a package registry + +Using the features of the package registry, it is possible to use one project to store all of your packages. + +This guide mirrors the creation of [this package registry](https://gitlab.com/sabrams/my-package-registry). + +For the video version, see [Single Project Package Registry Demo](https://youtu.be/ui2nNBwN35c). + +## How does this work? + +You might be wondering "how is it possible to upload two packages from different codebases to the same project on GitLab?". + +It is easy to forget that a package on GitLab belongs to a project, but a project does not have to be a code repository. +The code used to build your packages can be stored anywhere - maybe it is another project on GitLab, or maybe a completely +different system altogether. All that matters is that when you configure your remote repositories for those packages, you +point them at the same project on GitLab. + +## Why would I do this? + +There are a few reasons you might want to publish all your packages to one project on GitLab: + +1. You want to publish your packages on GitLab, but to a project that is different from where your code is stored. +1. You would like to group packages together in ways that make sense for your usage (all NPM packages in one project, + all packages being used by a specific department in one project, all private packages in one project, etc.) +1. You want to use one remote for all of your packages when installing them into other projects. +1. You would like to migrate your packages to a single place on GitLab from a third-party package registry and do not + want to worry about setting up separate projects for each package. +1. You want to have your CI pipelines build all of your packages to one project so the individual responsible for +validating packages can manage them all in one place. + +## Example walkthrough + +There is no functionality specific to this feature. All we are doing is taking advantage of functionality available in each +of the package management systems to publish packages of different types to the same place. + +Let's take a look at how you might create a public place to hold all of your public packages. + +### Create a project + +First, create a new project on GitLab. It does not have to have any code or content. Make note of the project ID +displayed on the project overview page, as you will need this later. + +### Create an access token + +All of the package repositories available on the GitLab package registry are accessible using [GitLab personal access +tokens](../../profile/personal_access_tokens.md). + +While using CI, you can alternatively use CI job tokens (`CI_JOB_TOKEN`) to authenticate. + +### Configure your local project for the GitLab registry and upload + +There are many ways to use this feature. You can upload all types of packages to the same project, +split things up based on package type, or package visibility level. + +The purpose of this tutorial is to demonstrate the root idea that one project can hold many unrelated +packages, and to allow you to discover the best way to use this functionality yourself. + +#### NPM + +If you are using NPM, this involves creating an `.npmrc` file and adding the appropriate URL for uploading packages +to your project using your project ID, then adding a section to your `package.json` file with a similar URL. + +Follow +the instructions in the [GitLab NPM Registry documentation](../npm_registry/index.md#authenticating-to-the-gitlab-npm-registry). Once +you do this, you will be able to push your NPM package to your project using `npm publish`, as described in the +[uploading packages](../npm_registry/index.md#uploading-packages) section of the docs. + +#### Maven + +If you are using Maven, this involves updating your `pom.xml` file with distribution sections, including the +appropriate URL for your project, as described in the [GitLab Maven Repository documentation](../maven_repository/index.md#project-level-maven-endpoint). +Then, you need to add a `settings.xml` file and [include your access token](../maven_repository/index.md#authenticating-with-a-personal-access-token). +Now you can [deploy Maven packages](../maven_repository/index.md#uploading-packages) to your project. + +#### Conan + +For Conan, first you need to add GitLab as a Conan registry remote. Follow the instructions in the [GitLab Conan Repository docs](../conan_repository/index.md#setting-the-conan-remote-to-the-gitlab-package-registry) +to do so. Then, create your package using the plus-separated (`+`) project path as your Conan user. For example, +if your project is located at `https://gitlab.com/foo/bar/my-proj`, then you can [create your Conan package](../conan_repository/index.md) +using `conan create . foo+bar+my-proj/channel`, where `channel` is your package channel (`stable`, `beta`, etc.). Once your package +is created, you are ready to [upload your package](../conan_repository/index.md#uploading-a-package) depending on your final package recipe. For example: + +```sh +CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan upload MyPackage/1.0.0@foo+bar+my-proj/channel --all --remote=gitlab +``` |