Publish ThreadX documentation to threadx.io

assigned to @malowe

changed due date to February 28, 2025

@malowe Can you please help @fdesbiens with his request. Let me know if you have any questions!

I can't open either of those repositories, they show as non-existent. If they are private repositories, I'll need to be granted access so I can see what the HTML looks like so I can figure out what I need to do for this.

@malowe I made an Otterdog PR to make the repositories public. They should be visible when you will see this.

I didn't push the HTML I generated to the repository but I can if you need it.

I didn't push the HTML I generated to the repository but I can if you need it.

@fdesbiens, that would be great. We can manage hosting the content; however, we would expect that the site's content is pre-built so our build script only needs to fetch the files.

This approach aligns with our expectations for projects publishing a website under eclipse.dev.

Projects are free to use the technology of their choice to manage their website, provided they deliver the final html in a Git repository!

Cheers!

The HTML version is in the repository, @cguindon.

[https://github.com/eclipse-threadx/rtos-docs-html](https://github.com/eclipse-threadx/rtos-docs-html)

I produced it using Bash scripts containing some hardcoded values. All the scripts did was invoke AsciiDoctor on each file with default settings.

Now, I have absolutely no idea how I could automate this when merging new commits in the AsciiDoc source repository. I have zero experience with GitHub actions. I can put together a robust recursive Bash script that will perform the conversion, but I need help for the automation.

The same goes for publishing the HTML to the website, of course.

The HTML version is in the repository, @cguindon.

Awesome, I will let @malowe review and he will let you know if he as any questions.

Now, I have absolutely no idea how I could automate this when merging new commits in the AsciiDoc source repository. I have zero experience with GitHub actions. I can put together a robust recursive Bash script that will perform the conversion, but I need help for the automation.

I think this is where either our releng team or @netomi, our GitHub SME, can assist you. I recommend creating a separate Helpdesk ticket to request their support.

We will continue using this issue to work with you on publishing the documentation to the website.

Created helpdesk ticket as suggested.

eclipsefdn/helpdesk#5610 (closed)

mentioned in issue eclipsefdn/helpdesk#5610 (closed)

added statewip label and removed statetodo label

mentioned in commit 4938dc3f

mentioned in merge request !16

mentioned in commit d4bdcb8d

@fdesbiens I've got a basic prototype working, are the current contents of the repository a release? If so, can you create a tag for it in GitHub? My working prototype is using a personal fork where I've added a tag just for validation purposes.

An example of this hosted for my prototype has an available link of https://preview-16--threadx-io.eclipsecontent.org/releases/6.1/netx-duo/. This will cover the last 2 points of the requirements at least! I have a few questions about the process, as there doesn't seem to be any kind of landing page from the asciidoc render. Is that something that is missing from the base? Additionally, is the path I picked out alright, or do we want a slightly different one?

For the first requirement, we should be able to make use of GitHub actions to automate a commit if needed, with something like this SO answer https://stackoverflow.com/a/72696837/13727794. I'll work to mock something up then run it by RelEng, who have done a lot of work with GH actions for stuff like Otterdog

We should probably set up a call to talk about this. I think there's enough gaps that a meeting would be better suited to address the issues!

Moving this out 2 weeks. While we're getting close and we have an active prototype, there are still some kinks in the process to iron out. Namely, landing pages and testing to ensure content is in a good state.

changed due date to March 14, 2025

@fdesbiens and I just finished a call and we came to these action items:

Frédéric will create an .adoc file as a landing page for a release
I will test/update the build script to ensure it works with branches instead of tags. This will also need an update to the above mentioned GH action that I can take care of.
I will create a landing page under /releases that will link to the landing pages of each of the provided sections.

We have changed from tags to branches to better support amendments to the documentation, and we will work together to make sure that the landing pages for the releases provide a consistent browsing experience.

Update, I've added a super basic landing page for releases, and the script is now working with branches. The only update left for functionality on my end is to make a patch so that we build + push all branches, which I can start today.

What content do you want on the releases home page? I have extremely simple copy text that I doubt will pass muster haha! https://preview-16--threadx-io.eclipsecontent.org/releases/

As a status update, the PR for the build update for pushing other branch builds is up now on GitHub: https://github.com/eclipse-threadx/rtos-docs-asciidoc/pull/5. I've made it not push main as currently we're looking at a model of versioned releases. If it's wanted, we can allow main to be built and pushed and we can have the "Latest" version up for review along with the rest of the numbered releases.

@fdesbiens let me know if you need support on the individual release landing page. I'm not sure what information we want on the overall landing page at this point, do you have any content or text you'd like to be put on that page?

Publish ThreadX documentation to threadx.io

What is left to be done

Designs

Child items ...

Activity