@prokod Hi

Here is a thing — this feature is still in a half-working state because it doesn't work perfectly out of the box.

For example, we want to have a link between alice.md and bob.md:

alice.md

<!-- Space: MARKTEST -->
<!-- Parent: mark -->
<!-- Title: Alice -->

Hello.
Here is the link on Bob: [bob](bob.md)

bob.md

<!-- Space: MARKTEST -->
<!-- Parent: mark -->
<!-- Title: Bob -->

Alice: [alice](alice.md)

If you run mark against alice.md and bob.md you will see two different results.

The confluence page called Alice will have a link to https://bob.md because the content of bob.md is not in Confluence at this moment, so Mark was not able to find it there and just put the link "as is".

Running mark against bob.md now will generate a correct link because mark will be able to find the Alice page in Confluence by the space/parent/title.

Therefore, you'll need to run mark against alice.md again to get the expected result.

This feature works without bugs, it's just the way how mark works — it deals with single files instead of dealing with a set of files.

But it still kind of sucks and I don't know how to deal with it yet. Calling mark twice is definitely not a good solution.

@kovetskiy Thanks! this explanation is clear now. Thx again!

@kovetskiy Hi again,

What about the working dir you run the tool from and the links created ?
I have the following tree:

|-roor-dir
  |- README.md
  |- dir-a
    |- dir-b
       |- toc.md
       |- chapter-a.md

• README.md has inside it a link to toc.md -> this works fine when syncing to Confluence
• toc.md has inside it a link to chapter-a.md -> this breaks already - the link is incorrect

I am running mark from root dir

Any idea ?

Unfortunately markdown links are not are not being replaced with Confluence links for me either. My project has the following structure:

|- apps
   |- README.md
   |- app1
      |- README.md
   |- app2
      |- README.md

When I put links in apps/README.md like this:

[App: app1](app1/README.md)

then run Mark using the file, the link in Confluence just appends app1/README.md to the end of current the URL.

Hi @kovetskiy

what you wrote here seem to not work with version 8.0. At least I couldn't reproduce it.

In general: Couldn't it work like mark would

1. check for a relative! link (by convention considered to belong to the documentation 'suite' and managed by mark) to another markdown (*.md) file,
2. get the title of the other file (the metadata headers from within the file or its H1) and error out or fail processing on invalid links (file not exists)
3. compute the link to a valid confluence link, like replace spaces with + and respecting other linked file's metadata (like space key - defaulting to the actual file's space key) and whatever else is needed. Then use the computed link when uploading the doc to confluence.

For 3. the 'compute'-logic to create a confluence link would most likely be manually reproduced within mark if the confluence API could not be leveraged for this. In theory, the compute logic could change with newer confluence versions so mark should internally choose the correct algorithm for the recognized version.

Does this make sense? I hope this idea would provide a base foundation and at least a first valuable iteration.

I think, this would be the key feature to close the gap between engineering people's way-of-working and maintainable and scalable corporate-level documentation requirements