Looks good.
A future optimization can deploy only the branch pages when a branch changes. Not sure it's feasible or worth the effort.

@dgarcia360 ^

It won't work. When a branch- related branch receives a new commit, it will take the versions defined in the conf.py of that branch instead of the ones defined in the default branch. We have a couple of issues opened to trigger the publication of release branches:

• Trigger publication when backporting sphinx-scylladb-theme#886
• Do not build docs for every version if there are not changes sphinx-scylladb-theme#124

When abranch-related branch receives a new commit, it will take the versions defined in the conf.py of that branch instead of the ones defined in the default branch.

@benipeled To sum up, we specify which branches we want to publish in conf.py on master/enterprise, so the workflow must run on master/enterprise. If we ran it on a different branch, it would take conf.py from that branch - but that conf.py would not be up to date.

I think we need to close this PR, but we'll queue scylladb/sphinx-scylladb-theme#886 to improve the current solution.
In the meantime, it would be great if I could run the Docs workflow manually to prevent publication delays.

When abranch-related branch receives a new commit, it will take the versions defined in the conf.py of that branch instead of the ones defined in the default branch.

@benipeled To sum up, we specify which branches we want to publish in conf.py on master/enterprise, so the workflow must run on master/enterprise. If we ran it on a different branch, it would take conf.py from that branch - but that conf.py would not be up to date.

If we have one conf.py for all versions - the one in the default branch - we can adjust the checkout to use the default branch, something like (we need to add another environment variable similar to the FLAG):

- name: Checkout
  uses: actions/checkout@v3
  with:
    ref: ${{ env.DEFAULT_BRANCH }}
    persist-credentials: false
    fetch-depth: 0

This way the pages will always be built from the default branch even when they'll trigger from another branch

Sounds good to me, but I need to defer to @dgarcia360.

• name: Checkout
  uses: actions/checkout@v3
  with:
  ref: ${{ env.DEFAULT_BRANCH }}
  persist-credentials: false
  fetch-depth: 0

@benipeled looks good. I'm testing the proposed solution in scylladb/sphinx-scylladb-theme#1023

If it works, could you please update this PR?

• name: Checkout
  uses: actions/checkout@v3
  with:
  ref: ${{ env.DEFAULT_BRANCH }}
  persist-credentials: false
  fetch-depth: 0

@benipeled looks good. I'm testing the proposed solution in scylladb/sphinx-scylladb-theme#1023

If it works, could you please update this PR?

Done

PS> I like the ${{ github.event.repository.default_branch }} you use on the other PR. In this case, I want to explicitly specify the required branch and not rely on an external variable that might change.

@benipeled LGTM. We tested the solution in sphinx-scylladb-theme and triggered a build from a branch: https://github.com/scylladb/sphinx-scylladb-theme/actions/runs/8154359635

@scylladb/scylla-maint please merge

@benipeled in the future, please use master as the target branch, not next.

@benipeled in the future, please use master as the target branch, not next.

Why? is it effect somehow the merge script?
I always change the target to next to avoid a case when someone will use the merge button on the PR page and merge it directly to the master