canonical-ubuntu-qa team mailing list archive

[Brian Murray <mp+449029@xxxxxxxxxxxxxxxxxx>]

Brian Murray has proposed merging autopkgtest-cloud:upstream-urls into autopkgtest-cloud:master.

Requested reviews:
  Canonical's Ubuntu QA (canonical-ubuntu-qa)

For more details, see:
https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/449029

I was reading the following documentation and noticed that some of the url's were now 404's.

https://autopkgtest-cloud.readthedocs.io/en/latest/administration.html#integration-with-github-and-gitlab-pull-merge-requests

I also changed one reference from master to main so that we are using more inclusive language.


-- 
Your team Canonical's Ubuntu QA is requested to review the proposed merge of autopkgtest-cloud:upstream-urls into autopkgtest-cloud:master.

diff --git a/docs/administration.rst b/docs/administration.rst
index c1513bf..e29cf58 100644
--- a/docs/administration.rst
+++ b/docs/administration.rst
@@ -230,7 +230,7 @@ If the tests live in the actual GitHub repo, this is all that is needed. If the
 tests live in the Debian/Ubuntu packaging repo, then your downstream
 ``debian/rules`` must ensure that, before it starts the package build, it
 replaces the downstream code from its own checkout with an upstream checkout of
-the pull request (and also drop all local patches). Look at `systemd's debian/rules <https://salsa.debian.org/systemd-team/systemd/blob/master/debian/rules>`_
+the pull request (and also drop all local patches). Look at `systemd's debian/rules <https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules>`_
 for an example, search for ``TEST_UPSTREAM``.
 
 However you want to structure your test, ensure that it works locally with a command like
@@ -259,7 +259,7 @@ On the GitHub project side:
    * ``build-git`` is the git clone URL of the repo that provides the
      autopkgtest (``debian/tests/``). If it's a Debian/Ubuntu packaging repo, that
      must check out the corresponding upstream code from the PR by itself (look
-     at `systemd's debian/rules <https://salsa.debian.org/systemd-team/systemd/blob/master/debian/rules>`_
+     at `systemd's debian/rules <https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules>`_
      for an example, search for ``TEST_UPSTREAM``). If the GitHub project to be
      tested contains the autopkgtest by itself, then don't specify this parameter
      at all; it will be dynamically generated as ``clone_url#refs/pull/<PR
@@ -267,7 +267,7 @@ On the GitHub project side:
    * ``package`` is merely an identifier for the project name/test which will be
      used for the results in swift. It is ''not'' related to Ubuntu package
      names at all, as the test will come from a git branch. Use the project
-     name, possibly with some suffix like ``-master`` if you have several
+     name, possibly with some suffix like ``-main`` if you have several
      different kinds of tests.
    * ``ppa`` specifies a ``launchpaduser/ppaname``. This must always be present
      so that the results don't land in the Ubuntu results Swift containers. The