Delete orphaned page on translated-content fails unless CONTENT_TRANSLATED_ROOT is an absolute path

Steps to reproduce

1. Set up both repositories (mdn/content and mdn/translated-content) (incl. installing node, yarn)
2. Set up .env file accordingly (CONTENT_TRANSLATED_ROOT=../translated-content/files)
3. Check some orphaned pages which are obsolete under fr
4. Run yarn content delete orphaned/Learn/How_to_contribute fr from translated-content local directory. Got ‘Command content not found’
5. Move to content directory
6. Run yarn content delete orphaned/Learn/How_to_contribute fr
7. Confirm the deletion

Actual result

Failed with

Error running git rm,-r,../translated-content/files/fr/orphaned/learn/how_to_contribute
<Buffer … more bytes>

error: git command failed: fatal: ../translated-content/files/fr/orphaned/learn/how_to_contribute : '../translated-content/files/fr/orphaned/learn/how_to_contribute' est hors du dépôt
       

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Sorry for the French here: the git command fails because the path is outside of the repository.

Expected result

Deletion goes smoothly and I’m able to submit a corresponding PR on mdn/translated-content

The thing is that I don’t know where this issue belongs:

• mdn/yari where cli.js is defined
• mdn/content where package.json includes the content script
• mdn/translated-content which has nothing of that.

Let me know where this should go (if not here) so that I can work on a fix.

[peterbe]

deleting orphaned pages works for me. I’m fairly sure the issue is the relative CONTENT_TRANSLATED_ROOT we should make this explicit that it should be an absolute path.

I think we should treat that as a bug. It’s nice to know you can unblock yourself by making it absolute but it seems like it should be fixed. For example, we have that code that checks if the CONTENT_ROOT was lacking the files suffix. I think we should do something similar to CONTEN_TRANSLATED_ROOT.

@fiji-flo Would you mind looking into it?

[peterbe]

In content/constants.js we check that fs.existsSync(CONTENT_TRANSLATED_ROOT) but it still managed to crash because the context (aka current working directory) in which the delete was run isn’t the same as when things started up.

I wonder if we can do this:

} else if (!fs.existsSync(CONTENT_ROOT)) {
  throw new Error(`${path.resolve(CONTENT_ROOT)} does not exist`);
-}
+} else if (CONTENT_ROOT !== fs.realpathSync(CONTENT_ROOT)) {
+   // Force it to be absolute in case it gets used from a different working directory. 
+   CONTENT_ROOT = fs.realpathSync(CONTENT_ROOT)
+}

Would that have solved the bug?