Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
Antora
Antora
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 176
    • Issues 176
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 34
    • Merge requests 34
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Antora
  • AntoraAntora
  • Merge requests
  • !610

Open
Created Nov 13, 2020 by David Jencks@djencksGuest
  • Report abuse
Report abuse

resolves Issue 188: symlinks

  • Overview 0
  • Commits 1
  • Pipelines 24
  • Changes 105

This is now ready for initial review. packages/content-aggregator/devdocs/symlinks.adoc attempts to explain what it does and how; it also includes a lot of historical cruft.

  • In the nature of things, a lot more information about problems is available through git than through the worktree file system access. At this point I suggest we output the information available from each source. It would be possible perhaps to replace the file system scanning and get the equivalent info, but if that's desirable lets do it later.

  • At the moment, the git access 'logs' to console.error detailed information about the problem and just continues. This is my preferred behavior... I like to get as far as possible to find out about as many errors as possible at once. I'd be completely open to failing at the end of content-aggregation if there are any of these symlink errors. I'd argue strongly against stopping after the first one. (The worktree support stops after the first symlink error, and I haven't discovered a way to avoid that).

  • In order to understand what was going on I had to add a bunch of (console) logging, which I've left in place behind a DEBUG && expression. Since we plan to add logging soon (!) I'd suggest leaving this here for easy conversion to trace level logging.

  • There are some test scenarios for unsupported cases, without a test. I checked "by hand" that these don't cause serious problems, but I'm not sure if or how there could be automated tests for them.

  • I don't understand quite why the 'skip' test doesn't work and why it thinks it needs to know a remote, but it's a pretty odd scenario. The previous test, building against the Antora worktree, might be overkill.

  • I wrote a couple little timing tests. I think the code can be simplified and made easier to understand by always having a posixify function, that's no-op on posix. That is faster. I also think checking for ':' and then running a regex that starts by checking for ':' is rather bogus, and just using the regex is only marginally slower AFAICT.

Edited Nov 19, 2020 by David Jencks
Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: issue-188-symlinks