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

Version's Number Missing in Generated Docs from Model Documentation Generation Script #1106

Closed
aj-stein-nist opened this issue Jan 25, 2022 · 2 comments
Assignees
Labels

Comments

@aj-stein-nist
Copy link
Contributor

aj-stein-nist commented Jan 25, 2022

Describe the bug

During code review for #941, we have discussed it in #941 (comment) but not tracked it yet. The code in generate-model-documentation.sh for the main branch and drafting website docs for the REVISION=latest configuration is not properly parsing out the proper number, so VERSION="${VERSION/#"v"}" is bound to just v, as evidenced in the current copy of the OSCAL docs. This will need a fix.

Who is the bug affecting?

Technical users who consume the OSCAL reference docs around the models.

What is affected by this bug?

Minor, but leads to confusion around what is the latest release version to which are documentation points to.

When does this occur?

Consistently

How do we replicate the issue?

Use the build/ci-cd/generate-model-documentation.sh script locally and run docs/run-server.sh to see the reference documentation points to only a version of v, not v1.x.y or something timely.

Expected behavior (i.e. solution)

The version number is properly parsed from git commands.

@aj-stein-nist aj-stein-nist changed the title Version's Number Missing in Generated Content from Model Documentation Generation Script Version's Number Missing in Generated Docs from Model Documentation Generation Script Jan 25, 2022
@aj-stein-nist aj-stein-nist self-assigned this Jan 28, 2022
@aj-stein-nist
Copy link
Contributor Author

I will try and take a look at this during the upcoming week, @david-waltermire-nist. Assigned it to myself.

@aj-stein-nist
Copy link
Contributor Author

aj-stein-nist commented Jan 31, 2022

Per discussion with Dave, this was resolved as part of the 1.0.1 release cleanup by ensuring the git checkout depth is not at a max of 1. Pulling in full history allows tag resolution.

Relevant commit is ae4f200.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant