From 86cac4de75fced27776df2696dd547676a20c472 Mon Sep 17 00:00:00 2001 From: Christian Vogel Date: Sat, 20 Mar 2021 19:16:41 +0100 Subject: [PATCH 1/4] recovered ssh agent forwarding documentation The documentation about ssh agent forwarding got lost when osxfs.md was deleted. So I just want to add the old documentation again at some place where users might look for it. This is the commit of the old documentation: https://github.com/docker/docker.github.io/commit/4dc68449055a8b734a1246004384de52144fd3fe#diff-124453101199ad6385df8981138b4ede623649e8b8b62ee7782be41830034b3a --- desktop/mac/networking.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/desktop/mac/networking.md b/desktop/mac/networking.md index 9739b5f047..4304980c84 100644 --- a/desktop/mac/networking.md +++ b/desktop/mac/networking.md @@ -44,6 +44,32 @@ syntax for `-p` is `HOST_PORT:CLIENT_PORT`. See [Proxies](index.md#proxies). +### SSH agent forwarding + +Docker Desktop for Mac allows you to use the host’s SSH agent inside a container. To do this: + +1. Bind mount the SSH agent socket by adding the following parameter to your `docker run` command: + + `--mount type=bind,src=/run/host-services/ssh-auth.sock,target=/run/host-services/ssh-auth.sock` + +1. Add the `SSH_AUTH_SOCK` environment variable in your container: + + `-e SSH_AUTH_SOCK="/run/host-services/ssh-auth.sock"` + +To enable the SSH agent in Docker Compose, add the following flags to your service: + + ```yaml +services: + web: + image: nginx:alpine + volumes: + - type: bind + source: /run/host-services/ssh-auth.sock + target: /run/host-services/ssh-auth.sock + environment: + - SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock + ``` + ## Known limitations, use cases, and workarounds Following is a summary of current limitations on the Docker Desktop for {{Arch}} From 0cdea41d41d1e8d2e01de61cd9e4c7ac0904ba79 Mon Sep 17 00:00:00 2001 From: Mathieu Champlon Date: Mon, 18 Oct 2021 12:05:25 +0200 Subject: [PATCH 2/4] Make it clearer how to update from Desktop 4.1.0 from the menu (#13696) * Make it clearer how to update from Desktop 4.1.0 from the menu * Minor format changes Co-authored-by: Usha Mandya <47779042+usha-mandya@users.noreply.github.com> --- desktop/mac/release-notes/index.md | 8 +++++--- desktop/windows/release-notes/index.md | 1 - 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/desktop/mac/release-notes/index.md b/desktop/mac/release-notes/index.md index 49adddb5b5..bdfd8ce003 100644 --- a/desktop/mac/release-notes/index.md +++ b/desktop/mac/release-notes/index.md @@ -27,9 +27,11 @@ This page contains information about the new features, improvements, known issue ### Bug fixes and minor changes -- Fixed a bug where a `Docker.qcow2` file would be ignored on upgrade and a fresh `Docker.raw` used instead, resulting in containers and images disappearing. If a system has both files (due to the previous bug) then the most recently modified file will be used, to avoid recent containers and images disappearing again. To force the use of the old `Docker.qcow2`, delete the newer `Docker.raw` file. Fixes [docker/for-mac#5998](https://github.com/docker/for-mac/issues/5998). -- Fixed update notification overlay sometimes getting out of sync between the Settings button and the Software update button in the Dashboard. -- Fixed menu entry to install a downloaded new Desktop update. When an update is ready to install `Restart` should change to `Update and restart`. +> When upgrading from 4.1.0, the Docker menu does not change to **Update and restart** so you can just wait for the download to complete (icon changes) and then select **Restart**. This bug is fixed in 4.1.1, for future upgrades. + +- Fixed a bug where a `Docker.qcow2` file would be ignored on upgrade and a fresh `Docker.raw` used instead, resulting in containers and images disappearing. If a system has both files (due to the previous bug), then the most recently modified file will be used to avoid recent containers and images disappearing again. To force the use of the old `Docker.qcow2`, delete the newer `Docker.raw` file. Fixes [docker/for-mac#5998](https://github.com/docker/for-mac/issues/5998). +- Fixed the update notification overlay sometimes getting out of sync between the **Settings** button and the **Software update** button in the Docker Dashboard. +- Fixed the menu entry to install a newly downloaded Docker Desktop update. When an update is ready to install, the **Restart** option changes to **Update and restart**. ## Docker Desktop 4.1.0 2021-09-30 diff --git a/desktop/windows/release-notes/index.md b/desktop/windows/release-notes/index.md index 8652ec4633..8390ed282a 100644 --- a/desktop/windows/release-notes/index.md +++ b/desktop/windows/release-notes/index.md @@ -29,7 +29,6 @@ This page contains information about the new features, improvements, known issue - Fixed a regression in WSL 2 integrations for some distros (e.g. Arch or Alpine). Fixes [docker/for-win#12229](https://github.com/docker/for-win/issues/12229) - Fixed update notification overlay sometimes getting out of sync between the Settings button and the Software update button in the Dashboard. - ## Docker Desktop 4.1.0 2021-09-30 From d5f0df3922dd17584a1cddffed30b936ebbfb856 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Wed, 20 Oct 2021 17:34:52 +0200 Subject: [PATCH 3/4] docker-hub: various touch-ups and some rephrasing - moved note about open source projects into the CTA; this reduces the number of notes on this page (which was already quite large), and puts related information about upgrading/plans in a central location. - changed note about limits to body text, and added mention of "business" plan. - replaced https://docs.docker.com URLs with local links - replaced some HTML links with links to the target markdown file - add missing YAML and "console" code-hints - wrapped long paragraphs/lines - corrected the information about Amazon Linux To be looked at; the recent changes added information about using "v2" compose files, but compose (after having switched to the compose-spec) no longer uses versions, so perhaps this needs to be corrected (we don't have local docs for the compose-spec format though, so that makes it a bit more complicated). Signed-off-by: Sebastiaan van Stijn --- docker-hub/builds/advanced.md | 61 +++++++++++----- docker-hub/builds/automated-testing.md | 19 +++-- docker-hub/builds/index.md | 98 +++++++++++++++----------- 3 files changed, 114 insertions(+), 64 deletions(-) diff --git a/docker-hub/builds/advanced.md b/docker-hub/builds/advanced.md index 870db9459b..c6c4bbd32c 100644 --- a/docker-hub/builds/advanced.md +++ b/docker-hub/builds/advanced.md @@ -6,7 +6,8 @@ redirect_from: - /docker-cloud/builds/advanced/ --- -The following options allow you to customize your automated build and automated test processes. +The following options allow you to customize your automated build and automated +test processes. ## Environment variables for building and testing @@ -29,7 +30,7 @@ If you are using these build environment variables in a `docker-compose.test.yml` file for automated testing, declare them in your `sut` service's environment as shown below. -```none +```yaml services: sut: build: . @@ -44,7 +45,8 @@ services: Docker Hub allows you to override and customize the `build`, `test` and `push` commands during automated build and test processes using hooks. For example, you might use a build hook to set build arguments used only during the build -process. (You can also set up [custom build phase hooks](#custom-build-phase-hooks) to perform actions in between these commands.) +process. (You can also set up [custom build phase hooks](#custom-build-phase-hooks) +to perform actions in between these commands.) **Use these hooks with caution.** The contents of these hook files replace the basic `docker` commands, so you must include a similar build, test or push @@ -53,9 +55,14 @@ command in the hook or your automated process does not complete. To override these phases, create a folder called `hooks` in your source code repository at the same directory level as your Dockerfile. Create a file called `hooks/build`, `hooks/test`, or `hooks/push` and include commands that the -builder process can execute, such as `docker` and `bash` commands (prefixed appropriately with `#!/bin/bash`). +builder process can execute, such as `docker` and `bash` commands (prefixed +appropriately with `#!/bin/bash`). -These hooks will be running on an instance of [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/){:target="_blank" rel="noopener" class="_"}, a distro based on Ubuntu, which includes interpreters such as Perl and Python and utilities such as `git` or `curl`. Please check the link above for the full list. +These hooks will be running on an instance of [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/){:target="_blank" rel="noopener" class="_"}, +a distro based on Red Hat Enterprise Linux (RHEL), which includes interpreters +such as Perl or Python, and utilities such as `git` or `curl`. Refer to the +[Amazon Linux 2 documentation](https://aws.amazon.com/amazon-linux-2/faqs/){:target="_blank" rel="noopener" class="_"} +for the full list of available interpreters and utilities. ## Custom build phase hooks @@ -65,7 +72,9 @@ autotest processes. Create a folder called `hooks` in your source code repository at the same directory level as your Dockerfile. Place files that define the hooks in that -folder. Hook files can include both `docker` commands, and `bash` commands as long as they are prefixed appropriately with `#!/bin/bash`. The builder executes the commands in the files before and after each step. +folder. Hook files can include both `docker` commands, and `bash` commands as +long as they are prefixed appropriately with `#!/bin/bash`. The builder executes +the commands in the files before and after each step. The following hooks are available: @@ -81,27 +90,36 @@ The following hooks are available: #### Override the "build" phase to set variables -Docker Hub allows you to define build environment variables either in the hook files, or from the automated build interface (which you can then reference in hooks). +Docker Hub allows you to define build environment variables either in the hook +files, or from the automated build interface (which you can then reference in hooks). -In the following example, we define a build hook that uses `docker build` arguments to set the variable `CUSTOM` based on the value of variable we defined using the Docker Hub build settings. `$DOCKERFILE_PATH` is a variable that we provide with the name of the Dockerfile we wish to build, and `$IMAGE_NAME` is the name of the image being built. +In the following example, we define a build hook that uses `docker build` arguments +to set the variable `CUSTOM` based on the value of variable we defined using the +Docker Hub build settings. `$DOCKERFILE_PATH` is a variable that we provide with +the name of the Dockerfile we wish to build, and `$IMAGE_NAME` is the name of +the image being built. -```none -docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME . +```console +$ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME . ``` > **Caution**: A `hooks/build` file overrides the basic [docker build](../../engine/reference/commandline/build.md) command used by the builder, so you must include a similar build command in the hook or the automated build fails. -To learn more about Docker build-time variables, see the [docker build documentation](../../engine/reference/commandline/build.md#set-build-time-variables---build-arg). +Refer to the [docker build documentation](../../engine/reference/commandline/build.md#set-build-time-variables---build-arg) +to learn more about Docker build-time variables. #### Push to multiple repos -By default the build process pushes the image only to the repository where the build settings are configured. If you need to push the same image to multiple repositories, you can set up a `post_push` hook to add additional tags and push to more repositories. +By default the build process pushes the image only to the repository where the +build settings are configured. If you need to push the same image to multiple +repositories, you can set up a `post_push` hook to add additional tags and push +to more repositories. -```none -docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT -docker push $DOCKER_REPO:$SOURCE_COMMIT +```console +$ docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT +$ docker push $DOCKER_REPO:$SOURCE_COMMIT ``` ## Source Repository / Branch Clones @@ -117,9 +135,14 @@ you do one of the following: * You can get a shallow checkout of the target branch by doing the following: - git fetch origin branch:mytargetbranch --depth 1 + ```console + $ git fetch origin branch:mytargetbranch --depth 1 + ``` -* You can also "unshallow" the clone, which fetches the whole Git history (and potentially -takes a long time / moves a lot of data) by using the `--unshallow` flag on the fetch: +* You can also "unshallow" the clone, which fetches the whole Git history (and + potentially takes a long time / moves a lot of data) by using the `--unshallow` + flag on the fetch: - git fetch --unshallow origin + ```console + $ git fetch --unshallow origin + ``` diff --git a/docker-hub/builds/automated-testing.md b/docker-hub/builds/automated-testing.md index 3d6f75b0cc..8c7a789f91 100644 --- a/docker-hub/builds/automated-testing.md +++ b/docker-hub/builds/automated-testing.md @@ -8,8 +8,9 @@ title: Automated repository tests --- Docker Hub can automatically test changes to your source code repositories -using containers. You can enable `Autotest` on [any Docker Hub repository](/docker-hub/repos) to run tests on each pull request to the source code -repository to create a continuous integration testing service. +using containers. You can enable `Autotest` on [any Docker Hub repository](../repos.md) +to run tests on each pull request to the source code repository to create a +continuous integration testing service. Enabling `Autotest` builds an image for testing purposes, but does **not** automatically push the built image to the Docker repository. If you want to push @@ -24,7 +25,7 @@ contains the Dockerfile used to build the image. For example: -```none +```yaml services: sut: build: . @@ -38,8 +39,16 @@ You can define any number of linked services in this file. The only requirement is that `sut` is defined. Its return code determines if tests passed or not. Tests **pass** if the `sut` service returns `0`, and **fail** otherwise. -> **Note**: Only the `sut` service and all other services listed in [`depends_on`](https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on) are started. For instance, if you have services that poll for changes in other services, be sure to include the polling services in the [`depends_on`](https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on) list to make sure all of your services start. -Also make sure to include a compose file version from 2.0 upward as `depends_on` was added in [version 2.0](https://docs.docker.com/compose/compose-file/compose-versioning/#version-2) file format. +> **Note** +> +> Only the `sut` service and all other services listed in +> [`depends_on`](../../compose/compose-file/compose-file-v2.md#depends_on) are +> started. If you have services that poll for changes in other services, be sure +> to include the polling services in the [`depends_on`](../../compose/compose-file/compose-file-v2.md#depends_on) +> list to make sure all of your services start. +> Also make sure to include a compose file version from 2.0 upward as `depends_on` +> was added in [version 2.0](../../compose/compose-file/compose-versioning.md#version-2) +> file format. You can define more than one `docker-compose.test.yml` file if needed. Any file that ends in `.test.yml` is used for testing, and the tests run sequentially. diff --git a/docker-hub/builds/index.md b/docker-hub/builds/index.md index 8aa24fc79e..912b70a9e5 100644 --- a/docker-hub/builds/index.md +++ b/docker-hub/builds/index.md @@ -11,7 +11,7 @@ title: Set up Automated Builds --- {% include upgrade-cta.html - body="The Automated Builds feature is available for Docker Pro, Team, and Business users. Upgrade now to automatically build and push your images." + body="The Automated Builds feature is available for Docker Pro, Team, and Business users. Upgrade now to automatically build and push your images. If you are using automated builds for an open-source project, you can join our [Open Source Community](https://www.docker.com/community/open-source/application){: target='_blank' rel='noopener' class='_'} program to learn how Docker can support your project on Docker Hub." header-text="This feature requires a Docker subscription" target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_auto_builds" %} @@ -19,12 +19,7 @@ title: Set up Automated Builds ## How Automated Builds work Docker Hub can automatically build images from source code in an external -repository and automatically push the built image to your Docker -repositories. - -> **Note** -> -> If you are using automated builds for an open-source project, you can join our [Open Source Community](https://www.docker.com/community/open-source/application){: target="_blank" rel="noopener" class="_"} program to learn how Docker can support your project on Docker Hub. +repository and automatically push the built image to your Docker repositories. When you set up automated builds (also called autobuilds), you create a list of branches and tags that you want to build into Docker images. When you push code @@ -42,14 +37,14 @@ pushing to the registry. You can use these tests to create a continuous integration workflow where a build that fails its tests does not push the built image. Automated tests do not push images to the registry on their own. [Learn more about automated image testing here.](automated-testing.md) -Depending on your [plan](https://www.docker.com/pricing){: target="_blank" rel="noopener" class="_"}, you may get concurrent builds, which means that `N` -autobuilds can be run at the same time. `N` is configured by the plan that you -subscribe to. Once `N+1` builds are running, any additional builds are -queued to be run later. +Depending on your [plan](https://www.docker.com/pricing){: target="_blank" rel="noopener" class="_"}, +you may get concurrent builds, which means that `N` autobuilds can be run at the +same time. `N` is configured by the plan that you subscribe to. Once `N+1` builds +are running, any additional builds are queued to be run later. -> **Note** -> -> The total number of pending builds in the queue is limited to 30 and further requests will be discarded. The number of concurrent builds for Pro is 5 and for Team is 15. +The total number of pending builds in the queue is limited to 30 and further +requests will be discarded. The number of concurrent builds for Pro is 5 and +for Team and Business is 15. ![An automated build dashboard](images/index-dashboard.png) @@ -66,9 +61,10 @@ Builds can be added to existing repositories, or added when you create a reposit 2. Click the **Builds** tab. -3. If you are setting up automated builds for the first time, select -the code repository service (GitHub or Bitbucket) where the image's source code is stored. -You might redirected to the settings page to [link](link-source.md) the code repository service. +3. If you are setting up automated builds for the first time, select the code + repository service (GitHub or Bitbucket) where the image's source code is stored. + You may be redirected to the settings page to [link](link-source.md) the code + repository service. Otherwise, if you are editing the build settings for an existing automated build, click **Configure automated builds**. @@ -79,10 +75,10 @@ You might redirected to the settings page to [link](link-source.md) the code rep source code provider. Once you select a namespace, its source code repositories appear in the **Select repository** dropdown list. -5. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository). +5. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository). -6. Review the default **Build Rules**, and optionally click the -**plus sign** to add and configure more build rules. +6. Review the default **Build Rules**, and optionally click the + **plus sign** to add and configure more build rules. _Build rules_ control what Docker Hub builds into images from the contents of the source code repository, and how the resulting images are tagged @@ -92,7 +88,7 @@ You might redirected to the settings page to [link](link-source.md) the code rep default set builds from the `Branch` in your source code repository called `master`, and creates a Docker image tagged with `latest`. -7. For each branch or tag, enable or disable the **Autobuild** toggle. +7. For each branch or tag, enable or disable the **Autobuild** toggle. Only branches or tags with autobuild enabled are built, tested, *and* have the resulting image pushed to the repository. Branches with autobuild @@ -101,13 +97,14 @@ You might redirected to the settings page to [link](link-source.md) the code rep 8. For each branch or tag, enable or disable the **Build Caching** toggle. - [Build caching](../../develop/develop-images/dockerfile_best-practices.md#leverage-build-cache) can save time if you are building a large image frequently or have + [Build caching](../../develop/develop-images/dockerfile_best-practices.md#leverage-build-cache) + can save time if you are building a large image frequently or have many dependencies. You might want to leave build caching disabled to make sure all of your dependencies are resolved at build time, or if you have a large layer that is quicker to build locally. 9. Click **Save** to save the settings, or click **Save and build** to save and -run an initial test. + run an initial test. A webhook is automatically added to your source code repository to notify Docker Hub on every push. Only pushes to branches that are listed as the @@ -124,9 +121,8 @@ In the **Build Rules** section, enter one or more sources to build. For each source: -* Select the **Source type** to build either a **tag** or a - **branch**. This tells the build system what to look for in the source code - repository. +* Select the **Source type** to build either a **tag** or a **branch**. This + tells the build system what to look for in the source code repository. * Enter the name of the **Source** branch or tag you want to build. @@ -144,11 +140,16 @@ For each source: capture groups and use its result as part of the tag. To learn more, see [regexes](index.md#regexes-and-automated-builds). -* Specify the **Dockerfile location** as a path relative to the root of the source code repository. (If the Dockerfile is at the repository root, leave this path set to `/`.) +* Specify the **Dockerfile location** as a path relative to the root of the source + code repository. If the Dockerfile is at the repository root, leave this path + set to `/`. > **Note** > -> When Docker Hub pulls a branch from a source code repository, it performs a shallow clone (only the tip of the specified branch). Refer to [Advanced options for Autobuild and Autotest](advanced.md) for more information. +> When Docker Hub pulls a branch from a source code repository, it performs a +> shallow clone (only the tip of the specified branch). Refer to +> [Advanced options for Autobuild and Autotest](advanced.md#source-repository--branch-clones) +> for more information. ### Environment variables for builds @@ -201,8 +202,9 @@ display a **Retry** button. > **Note** > -> If you are viewing the build details for a repository that belongs -to an Organization, the Cancel and Retry buttons only appear if you have `Read & Write` access to the repository. +> If you are viewing the build details for a repository that belongs to an +> Organization, the Cancel and Retry buttons only appear if you have `Read & Write` +> access to the repository. ## Disable an automated build @@ -272,11 +274,15 @@ Depending on how the files are arranged in your source code repository, the files required to build your images may not be at the repository root. If that's the case, you can specify a path where the build looks for the files. -The _build context_ is the path to the files needed for the build, relative to the root of the repository. Enter the path to these files in the **Build context** field. Enter `/` to set the build context as the root of the source code repository. +The _build context_ is the path to the files needed for the build, relative to +the root of the repository. Enter the path to these files in the **Build context** +field. Enter `/` to set the build context as the root of the source code repository. > **Note** > -> If you delete the default path `/` from the **Build context** field and leave it blank, the build system uses the path to the Dockerfile as the build context. However, to avoid confusion we recommend that you specify the complete path. +> If you delete the default path `/` from the **Build context** field and leave +> it blank, the build system uses the path to the Dockerfile as the build context. +> However, to avoid confusion we recommend that you specify the complete path. You can specify the **Dockerfile location** as a path relative to the build context. If the Dockerfile is at the root of the build context path, leave the @@ -296,13 +302,16 @@ these in the **Docker Tag** field using `{\1}` through `{\9}`. ### Build images with BuildKit -Autobuilds use the BuildKit build system by default. If you want to use the legacy Docker build system, add the [environment variable](index.md#environment-variables-for-builds){: target="_blank" rel="noopener" class="_"} `DOCKER_BUILDKIT=0`. Refer to the [build images with BuildKit](../../develop/develop-images/build_enhancements.md) +Autobuilds use the BuildKit build system by default. If you want to use the legacy +Docker build system, add the [environment variable](index.md#environment-variables-for-builds){: target="_blank" rel="noopener" class="_"} +`DOCKER_BUILDKIT=0`. Refer to the [build images with BuildKit](../../develop/develop-images/build_enhancements.md) page for more information on BuildKit. ## Build repositories with linked private submodules @@ -314,11 +323,16 @@ submodules (or requires that you clone other private repositories to build), Docker Hub cannot access these additional repos, your build cannot complete, and an error is logged in your build timeline. -To work around this, you can set up your automated build using the `SSH_PRIVATE` environment variable to override the deployment key and grant Docker Hub's build system access to the repositories. +To work around this, you can set up your automated build using the `SSH_PRIVATE` +environment variable to override the deployment key and grant Docker Hub's build +system access to the repositories. > **Note** > -> If you are using autobuild for teams, use [the process below](index.md#service-users-for-team-autobuilds) instead, and configure a service user for your source code provider. You can also do this for an individual account to limit Docker Hub's access to your source repositories. +> If you are using autobuild for teams, use [the process below](index.md#service-users-for-team-autobuilds) +> instead, and configure a service user for your source code provider. You can +> also do this for an individual account to limit Docker Hub's access to your +> source repositories. 1. Generate a SSH keypair that you use for builds only, and add the public key to your source code provider account. @@ -333,11 +347,13 @@ To work around this, you can set up your automated build using the `SSH_PRIVATE` > **Note** > -> You must configure your private git submodules using git clone over SSH (`git@submodule.tld:some-submodule.git`) rather than HTTPS. +> You must configure your private git submodules using git clone over SSH +> (`git@submodule.tld:some-submodule.git`) rather than HTTPS. ## Autobuild for Teams -When you create an automated build repository in your own account namespace, you can start, cancel, and retry builds, and edit and delete your own repositories. +When you create an automated build repository in your own account namespace, you +can start, cancel, and retry builds, and edit and delete your own repositories. These same actions are also available for team repositories from Docker Hub if you are a member of the Organization's `Owners` team. If you are a member of a @@ -381,7 +397,9 @@ variable to automated builds associated with the account. 2. Create a "build" team in your organization. 3. Ensure that the new "build" team has access to each repository and submodule you need to build. - Go to the repository's **Settings** page. On GitHub, add the new "build" team to the list of **Collaborators and Teams**. On Bitbucket, add the "build" team to the list of approved users on the **Access management** screen. + Go to the repository's **Settings** page. On GitHub, add the new "build" team + to the list of **Collaborators and Teams**. On Bitbucket, add the "build" team + to the list of approved users on the **Access management** screen. 4. Add the service user to the "build" team on the source provider. @@ -408,4 +426,4 @@ integrates seamlessly with autobuild and autoredeploy. > **Note** > > While the Autotest feature builds an image for testing purposes, it -does not push the resulting image to Docker Hub. +> does not push the resulting image to Docker Hub. From d601e97f75efc9861d3e6a01226d4e84126105a2 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Wed, 20 Oct 2021 17:39:22 +0200 Subject: [PATCH 4/4] engine/install: remove apt-transport-https from instructions This package is no longer needed on all current distro versions we support. From the package description (https://packages.debian.org/buster/apt-transport-https); > This is a dummy transitional package - https support has been moved into the > apt package in 1.5. It can be safely removed. Verifying the version of apt that's available in Ubuntu and Debian: Ubuntu: docker run --rm ubuntu:xenial apt --version apt 1.2.35 (amd64) docker run --rm ubuntu:17.04 apt --version apt 1.4.6 (amd64) docker run --rm ubuntu:17.10 apt --version apt 1.5.2 (amd64) docker run --rm ubuntu:18.04 apt --version apt 1.6.14 (amd64) docker run --rm ubuntu:20.04 apt --version apt 2.0.6 (amd64) Debian: docker run --rm debian:stretch apt --version apt 1.4.11 (amd64) docker run --rm debian:buster apt --version apt 1.8.2.3 (amd64) docker run --rm debian:bullseye apt --version apt 2.2.4 (amd64) From the above; all currently supported versions of Ubuntu (18.04 and up), and Debian (old-stable and stable) have apt > 1.5, so we can remove this dependency from the installation instructions. Signed-off-by: Sebastiaan van Stijn --- engine/install/debian.md | 1 - engine/install/ubuntu.md | 1 - 2 files changed, 2 deletions(-) diff --git a/engine/install/debian.md b/engine/install/debian.md index dd16ccc3d9..dd16ff198d 100644 --- a/engine/install/debian.md +++ b/engine/install/debian.md @@ -83,7 +83,6 @@ from the repository. $ sudo apt-get update $ sudo apt-get install \ - apt-transport-https \ ca-certificates \ curl \ gnupg \ diff --git a/engine/install/ubuntu.md b/engine/install/ubuntu.md index fd9c59ee93..2ba1190173 100644 --- a/engine/install/ubuntu.md +++ b/engine/install/ubuntu.md @@ -105,7 +105,6 @@ from the repository. $ sudo apt-get update $ sudo apt-get install \ - apt-transport-https \ ca-certificates \ curl \ gnupg \