Skip to content

Conversation

@beauremus
Copy link
Contributor

My first pass attempt at automating source documentation for Dart and Rust.

Create two reusable workflows, one each for Dart and Rust to build and
deploy their docs using GitHub Pages.
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both workflows reference this steps.deployment.outputs.page_url variable. I think I'm missing where that comes from. Is that set by some other workflow?

Copy link
Contributor Author

@beauremus beauremus Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch! I used the example from the Action readme, but I don't think we need this anymore. Will push an update shortly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added an id: to the step. So, this output is generated by the Action.
What I'm not sure of is whether the environment needs to exist before being requested.
https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll merge after you approve

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the environment is set before the steps execute. So your url variable might just be empty

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the deploy-pages action require a url environment variable? Is that how that works?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is part of the README docs, but there's no further explanation.
https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments
This doc doesn't have it. So, let's remove the complexity until it's better understood.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking more closely at the actions/deploy-pages README, it seems like maybe the purpose is to kick out an auto-generated URL somewhere that a person could see it? Like, maybe the action comes up with the URL internally, so you'd need to have it reported into the environment variable in order to know where to look for the deployed pages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure there's some magic going on for sure. Without diving into the Action code, I'm not sure.

Copy link
Contributor

@jacob-curley-fnal jacob-curley-fnal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just had that one clarification question, but otherwise looks solid!

needs: build
steps:
- name: Deploy to GitHub Pages
id: dpeloyment
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may want to check spelling here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a linter/spell checker 😳

The url field in the environment and the id: deployment from the actions/deploy-pages@v4 step are no longer necessary as the action automatically sets the page URL. This commit cleans up these redundant configurations in both the Dart and Rust documentation deployment workflows.
Comment on lines +6 to +8
permissions:
pages: write # Needed to deploy
id-token: write # Needed for auth
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably need a contents: read entry as well. I'm getting errors when trying to call this, as default behavior is to only set the permissions that are provided here, and to try to use the lowest level permissions possible. My suspicion is that GitHub sees this as us "downgrading" the permissions from the calling workflow, since read is not specified. So it's dropping the read permissions and can't see the code in the repo anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will apply to all workflows. Right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any workflow that specifies permissions at this level, yes. The integration and deployment workflows just expect to have their permissions provided. They don't have any special permissions block like this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got a successful deployment! Only problem is that the permissions on the pages site are jank, so I can't access the actual docs 😆 Might be a problem at the repo level tho, or with the org permissions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to figure out the best way to consistently handle the URLs. I found the docs here https://studious-spoon-gz98yym.pages.github.io/reference/rust_env_var_lib/index.html 😅
Not great

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to figure out how to resolve the snake case package name for this step:

cp -r target/doc/* ./docs/reference

It should be

cp -r target/doc/rust_env_var_lib/* ./docs/

Copy link

@rneswold rneswold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome, Beau! I love having our docs available!

@rneswold
Copy link

Should we have it run a docs check pass in the PR and generate the docs when merging? (Is that what it does now?)

@jacob-curley-fnal
Copy link
Contributor

Ran into an issue while trying to use this in rust-pubsub-lib
When a Rust project uses a Fermi-internal Rust lib, it is not able to pull it into the project during cargo's doc command (even tho we're skipping the dependencies, it still wants to build the full project). Might need a flag similar to the integration workflow that triggers the use of the external git CLI rather than cargo's internal git adapter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants