Expand & update sections for command line usage

[CarlosLopezDeLara]

👋 Hello there! Welcome. Please follow the steps below to tell us about your contribution.

1. Please complete a Checklist
2. Fill in all sections of the template
3. Click "Create pull request"

Checklist

<-- Please fill the boxes with [x] before submitting a pull request -->

• [x] I have read the How to Contribute.
• [x] I have run yarn build after adding my changes without getting any errors.

Updating documentation or Bugfix

• Bring Cardano CLI documentation to developers.cardano.org as its official home from now onward.
• Update Cardano Node documentation
• Small reorganization to accommodate previously mentioned changes.

[CarlosLopezDeLara]

@rphair

from a first read of the source it looks like it will be a "user manual" for the CLI based features and I'm not aware of anything else like this, so it would be very welcome here.

That's exactly right. A few months ago, while discussing documentation topics with @KtorZ, he showed the anual survey where one the main weaknesses or concerns from the community was that documentation was a little bit too scattered. At the time I was working on having node and cli documentation on a docusaurus website, changed my mind, because of the survey: it makes it clear that ddevelopers.cardano.org is the most trusted and visited place to look for documentation. So we agreed that instead of having yet another website we would move our stuff to the developerss portal. In that regard, of course Mathias and Nicolas Cerny are well aware of this work.

(source of truth) To your knowledge, does this material have the same scope as any other CLI documentation? If so, how would the target audience be different between this material & any others?

The intention is to make developers.cardano.org the official place to look for end user documentation for Node and CLI. It has same scope, but extended to cover undocumented features. i.e. RTS flags in node are not discussed anywhere else. Moreover, after this is PR merged, I will remove end user documentation from other places, i.e. https://github.com/input-output-hk/cardano-node-wiki and most likely will update the course https://cardano-course.gitbook.io/cardano-course to be based on the developers.cardano.org.

(maintenance) Given the new terms that have been added to cardano-cli with each release, do you and/or associates plan to keep this material up to date going forward, or is this a one-time sync with the Conway release of the node & CLI?

That is the intention. We plan to maintain this up to date with future releases. Our goal is to archive or remove end user documentation from other places. Decentralized network is great, decentralized documentation is not. =)

[CarlosLopezDeLara]

@rphair The only merge conflict that shows up here is in yarn.lock. I need advise on how to resolve this conflicts. mainy because the file starts with

# This file is generated by running "yarn install" inside your project.
# Manual changes might be lost - proceed with caution!

OR 

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1

So, since this is an auto generated file, i'm puzzled about the merge conflict.

[rphair]

Then you should be fine if you remove the yarn.lock changes from this branch so it doesn't appear on the /files listing anymore, since you've already ruled out other merge conflicts.

The auto-generated comments above are from the yarn install command, which contributors never need to run unless yarn.lock gets clobbered in their branch. Generally all PRs here only submit documentation changes & are therefore built with the yarn.lock from the repository itself. If you generate a different yarn.lock in your local fork, just don't commit it.

Removing yarn.lock from a PR after committing it is a common problem for both contributors & editors so I wrote a blurb about how to fix the problem here: https://developers.cardano.org/docs/portal-contribute#i-committed-yarnlock-to-my-pr-branch-what-do-i-do

[katomm]

Wow this is huge. Thank you @CarlosLopezDeLara. I can help with resolving the conflicts.

[katomm]

@CarlosLopezDeLara you are obv faster than me. 😁 thank you

[CarlosLopezDeLara]

@rphair @katomm @thenic95

This should be ready for review

[katomm]

I'm on it.

[rphair]

@CarlosLopezDeLara thanks for your continuing attention, but what you did was not a rebase in the practical sense: since your PR at this time now contains all the changes to staging since you originally created this branch, as duplicates of the changes that have already been merged. For a quick verification of this fact, see the /files page where it appears as if you are contributing all the /blog entries since March.

I think you are at the point where you have to create a new branch based on an updated staging in your fork that includes only the changes you are making. There are ways of reconciling problems like this but I think these are no longer possible once a branch is submitted as a pull request, since the changes can no longer be "unwound" as if they had never happened. The most widely recommended solution is to recreate the PR.

If other editors contradict this recommendation & allow this PR to continue, it really would be fraught with merge conflicts unless work on every other affected page on the Dev Portal were suspended until this PR was merged... and even then we could face a plague of duplicated or omitted changes if not done perfectly. cc @katomm @fill-the-fill @rdlrt

[CarlosLopezDeLara]

@rphair you are right, looks like I screwed it a bit. I like your suggestion, it will be easier and faster to reconcile. I'll create new branch. Thus closing this PR.

[disassembler]

superseded by #1287 1287