You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given release tags are using "complex" prefix (e.g., pack/v<VERSION>), like in CMSIS-View.
On release, the documentation is pushed onto the gh-pages branch into a folder named like the tag. For plain tags (without / in the name) this results in a new top-level folder as expected. But for "complex" tag names (with / in the name) this creates a folder hierarchy.
For CMSIS-View for example, having the release tags pack/v1.0.0 and pack/v1.1.0 lead to the folder structure on gh-pages branch like this:
📦
┣ 📂 pack
┃ ┣ 📂 v1.0.0 release 1.0.0 documentation
┃ ┗ 📂 v1.1.0 release 1.1.0 documentation
┣ 📂 main main branch documentation
┣ 📂 latest -> pack/v1.1.0 link to latest release documentation
┗ 📋 versions.js Version selector
Unfortunately, when updating the versions.js file, searching for documentation versions is limited to the first directory level. This leads to documentation version published into some subfolder hierarchy not to be listed.
Expected behaviour
Instead, on the gh-pages branch all release versions should show up as s top-level folder named according to the release version. The release version is considered to be the tag name without the prefix.
For above example, the expected folder structure is like this:
📦
┣ 📂 1.0.0 release 1.0.0 documentation
┣ 📂 1.1.0 release 1.1.0 documentation
┣ 📂 main main branch documentation
┣ 📂 latest -> 1.1.0 link to latest release documentation
┗ 📋 versions.js Version selector
The text was updated successfully, but these errors were encountered:
Issue description
Given release tags are using "complex" prefix (e.g.,
pack/v<VERSION>
), like in CMSIS-View.On release, the documentation is pushed onto the
gh-pages
branch into a folder named like the tag. For plain tags (without/
in the name) this results in a new top-level folder as expected. But for "complex" tag names (with/
in the name) this creates a folder hierarchy.For CMSIS-View for example, having the release tags
pack/v1.0.0
andpack/v1.1.0
lead to the folder structure ongh-pages
branch like this:Unfortunately, when updating the
versions.js
file, searching for documentation versions is limited to the first directory level. This leads to documentation version published into some subfolder hierarchy not to be listed.Expected behaviour
Instead, on the
gh-pages
branch all release versions should show up as s top-level folder named according to the release version. The release version is considered to be the tag name without the prefix.For above example, the expected folder structure is like this:
The text was updated successfully, but these errors were encountered: