Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI - no absolute links to local pages #849

Merged
merged 18 commits into from
Dec 29, 2016
Merged

Conversation

aduermael
Copy link
Contributor

@aduermael aduermael commented Dec 12, 2016

Describe the proposed changes

New tests to make sure there are no absolute links to docs.docker.com in local pages.

  • makes sure all local pages referenced by links do exist (and not though redirects)
  • makes sure all redirects point to existing pages

edit: I'll take care of relative links checking in a different PR.

work in progress...

@johndmulhausen
Copy link

johndmulhausen commented Dec 12, 2016

Deploy preview ready!

Built with commit 1a70494

https://deploy-preview-849--docker-docs.netlify.com

@aduermael
Copy link
Contributor Author

Checks have passed! :)
@johndmulhausen can you merge it please?

I would like to start working on new tests for relative links to missing resources and potential redirect loops.

Also, don't you think it's time to enforce tests on master? Almost all PRs to master branch with no Jenkinsfile have been merged. And I would gladly drop comments in the remaining ones to ask for rebase.

Thanks!

@aduermael aduermael changed the title CI - check all links to local pages [DO NOT MERGE] CI - check all links to local pages Dec 19, 2016
@aduermael
Copy link
Contributor Author

@johndmulhausen that PR is good to go! 😊

@aduermael aduermael changed the title CI - check all links to local pages CI - check absolute links to local pages Dec 19, 2016
@aduermael aduermael changed the title CI - check absolute links to local pages CI - no absolute links to local pages Dec 19, 2016
@friism
Copy link
Contributor

friism commented Dec 19, 2016

lgtm

@aduermael
Copy link
Contributor Author

@friism thanks! :)

@johndmulhausen
Copy link

johndmulhausen commented Dec 20, 2016

@aduermael Right now the CI is failing due to a submodules error:

20:57:32 Checking out Revision cde5c50f47419b74ff69e27a0281403082f6ef7a (PR-849)
20:57:33  > git config core.sparsecheckout # timeout=10
20:57:33  > git checkout -f cde5c50f47419b74ff69e27a0281403082f6ef7a
[Pipeline] sh
20:57:35 [ker_docker.github.io_PR-849-SIO4KRLIUPX4JYS5AYGAJID7R4JI6TFWDRPVZVH7ADS3DWRI6QYA] Running shell script
20:57:36 + git submodule update --init
20:57:36 No submodule mapping found in .gitmodules for path 'tests/src/github.com/gdevillele/frontparser'
[Pipeline] }
[Pipeline] // wrap
[Pipeline] }
[Pipeline] // wrap
[Pipeline] }
[Pipeline] // withDockerRegistry
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline

GitHub has been notified of this commit’s build result

ERROR: script returned exit code 1
Finished: FAILURE

I think .gitmodules in root needs to exist and have the right entries in this PR.

@aduermael
Copy link
Contributor Author

@johndmulhausen Yes, Go deps are now vendored as submodules (you asked me to do it).
I don't know what's the right way to pull them using Jenkins. But I'll figure this out.

@johndmulhausen
Copy link

johndmulhausen commented Dec 21, 2016

It's great that we're gonna use submodules, thanks for that. Sorry it's creating this problem. Other than that, this PR is looking good. :) @mstanleyjones also did a pass at getting rid of old PRs so we should be able to turn on mandatory Jenkins very soon, though there are a couple bugs that need to be addressed first:

  1. Jenkins jobs taking hours sometimes, and
  2. Jenkins failing on inter-branch PRs, which we're gonna have all the time. That continuous-integration/jenkins/branch check would cause problems.

@aduermael
Copy link
Contributor Author

I fixed the issue with submodules, but meanwhile, new absolute links to docs.docker.com have been introduced... I'm fixing that.

@aduermael
Copy link
Contributor Author

Yay! All checks have passed! 🙂
@johndmulhausen, can you review it please?

Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
This reverts commit ca54f76.

We want to fix the root cause, not the symptoms. So let’s make sure original content is fine instead of fixing it at build.

Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
Signed-off-by: Adrien Duermael <adrien@duermael.com>
@aduermael
Copy link
Contributor Author

@johndmulhausen ?

@@ -82,7 +82,7 @@ enabled](troubleshoot.md#virtualization-must-be-enabled) in Troubleshooting.
<p />
* Nested virtualization scenarios, such as running Docker for Windows on a VMWare or Parallels instance, might work, but come with no guarantees (i.e., not officially supported).
<p />
* **What the Docker for Windows install includes**: The installation provides [Docker Engine](https://docs.docker.com/engine/userguide/intro/), Docker CLI client, [Docker Compose](https://docs.docker.com/compose/overview/), and [Docker Machine](https://docs.docker.com/machine/overview/).
* **What the Docker for Windows install includes**: The installation provides [Docker Engine](/engine/userguide/intro/), Docker CLI client, [Docker Compose](/compose/overview/), and [Docker Machine](/machine/overview/).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not introduced here, but shouldn't this be a link to a .md file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mstanleyjones I have no idea... 😕

@@ -478,15 +478,15 @@ You can configure options on the Docker daemon in the given JSON configuration f

![Docker Daemon](images/docker-daemon.png)

For a full list of options on the Docker daemon, see <a href="https://docs.docker.com/engine/reference/commandline/dockerd/" target="_blank">daemon</a> in the Docker Engine command line reference.
For a full list of options on the Docker daemon, see [daemon](/engine/reference/commandline/dockerd/) in the Docker Engine command line reference.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You changed the functionality of this link by removing the target attribute...

Copy link
Contributor Author

@aduermael aduermael Dec 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mstanleyjones I can use this syntax with Kramdown: [link](url){:target="_blank"}
I'll fix it now.


In that topic, see also:

* [Daemon configuration file](https://docs.docker.com/engine/reference/commandline/dockerd/#/daemon-configuration-file)
* [Daemon configuration file](/engine/reference/commandline/dockerd/#/daemon-configuration-file)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not introduced here, but these should point to the .md file if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mstanleyjones I can fix it if you're sure we should always link to md files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The correct Markdown should be:

[Daemon configuration file](/engine/reference/commandline/dockerd.md#daemon-configuration-file)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it expects relative URLs; ../engine/reference/commandline/docker.md#daemon-configuration-file ?

@@ -37,7 +37,7 @@ For a complete list of `docker-machine` subcommands, see the [Docker Machine sub

Users using their own Docker Registry will experience `x509: certificate signed by unknown authority`
error messages if their registry is signed by custom root Certificate Authority and it is
not registered with Docker Engine. As discussed in the [Docker Engine documentation](https://docs.docker.com/engine/security/certificates/#/understanding-the-configuration)
not registered with Docker Engine. As discussed in the [Docker Engine documentation](/engine/security/certificates/#/understanding-the-configuration)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, link to the .md if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mstanleyjones Same as above... Losing the anchor link

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mstanleyjones Also, one important point. Currently it is somehow better to use a path of this form: https://docs.docker.com/engine/reference/commandline/dockerd/
Instead of https://docs.docker.com/engine/reference/commandline/dockerd.md

Because the non-md form leads you right to the page you want. While the md form returns a terrible 404 error with a client side JS script that takes you to the non-md path...

We already mentioned that in the past, I really think it's an issue for SEO.

But I also think it makes more sense to link to local markdowns within markdowns. Maybe we should just update these links at build time.

Signed-off-by: Adrien Duermael <adrien@duermael.com>
as requested by @mstanleyjones

Signed-off-by: Adrien Duermael <adrien@duermael.com>
@aduermael
Copy link
Contributor Author

@mstanleyjones I added the missing target=_blank. And fixed some links to md files.
But I can't fix them all, as the one containing anchor links would be broken.

Please merge that PR as soon as possible, I don't want absolute links to be re-introduced.

@aduermael
Copy link
Contributor Author

@mstanleyjones @johndmulhausen Also, the Jenkins tests should be made required now. Please please please...

@aduermael
Copy link
Contributor Author

@mstanleyjones about that issue with links that should point to actual markdowns. I'm totally on board with this idea.
But I'm sure it happens in many files, and I would prefer to fix that in a dedicated PR, along with new tests for that particular issue. Because as of today, there's nothing making sure that will never happen again.
So can you please merge that one @mstanleyjones? I'll submit a new one to address that issue.
Thanks!
cc @thaJeztah @johndmulhausen

@mdlinville mdlinville merged commit ae629e5 into docker:master Dec 29, 2016
@aduermael
Copy link
Contributor Author

thank you @mstanleyjones 🙂

bermudezmt pushed a commit that referenced this pull request Nov 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants