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

How does read the docs detect tags and build /stable/ when triggering via the api? #6415

Open
Aricg opened this issue Nov 27, 2019 · 15 comments
Labels
Accepted Accepted issue on our roadmap Needed: documentation Documentation is required

Comments

@Aricg
Copy link

Aricg commented Nov 27, 2019

Details

so, looks like the default behavior is this:
read the docs wants a /latest/ and /stable/

Stable follows /branch/ unless it sees a tag
then it follows the tag.

I don't really understand how the tag detection works if you are not using a webhook
When using the api is readthedocs going to see all the new tags? and automatically build /stable/ and if so how does it do this?

User created a branch. (amber)
User tagged this branch at the same location it was created (1.3.0)
(So the tag and the head of the branch are the same ref)

no builds are triggered by our CI when a branch is created, this is fine.
the next time a user updates that branches docs/ directory
the branch will be created in read the docs as expected.

lftools rtd project-build-trigger o-ran-sc-portal-ric-dashboard amber

however, in testing I triggered on that branch manually

lftools rtd project-build-trigger o-ran-sc-portal-ric-dashboard amber

This casued read the docs to trigger a build for /amber/ and /stable/

The build shows that It did a:
git checkout --force origin/amber

Which pulled down this commit.
commit cec131cf4b0279bd6a6d4dd31642270cebe38711 (HEAD, tag: 1.3.0, origin/amber)

The head of my branch of "amber" happens to have a tag on it.
My guess read the docs saw the tag and decided
to trigger a build /stable/ after it was done with /amber/

/stable/ is following type "tag" and not the branch "amber"

lftools rtd project-version-details o-ran-sc-portal-ric-dashboard stable
<snip> 
'ref': '1.3.0',
'slug': 'stable',
'type': 'tag',

I did not expect this behavior.
Does read the docs have a way to detect tags if the build I trigger has a new tag somewhere in the history?
Or it it only detecting the tag because it exists at the head of the "amber" branch?

Thanks for your time.

@humitos
Copy link
Member

humitos commented Nov 28, 2019

lftools rtd project-build-trigger o-ran-sc-portal-ric-dashboard amber

This casued read the docs to trigger a build for /amber/ and /stable/

I don't know what this commands does behind the scenes. Although, if it's using APIv3 endpoint (https://docs.readthedocs.io/en/latest/api/v3.html#build-triggering), it should not trigger a build for stable version, only for amber

@Aricg
Copy link
Author

Aricg commented Nov 28, 2019

I think that the first time you build a branch it automatically builds stable, no?

@stsewd
Copy link
Member

stsewd commented Nov 28, 2019

So, when we detect at least a tag, we give more priority to tags. When you trigger a build to any version, rtd clones the repo and gets the branches and tags from there. Then it updates the versions, when updating the versions, it checks if the stable version has changed (new tag or new branch with a version greater than the current stable), it also triggers a build to latest if master has changed. Hope that answer your question.

@stsewd stsewd added Needed: more information A reply from issue author is required Support Support question labels Nov 28, 2019
@Aricg
Copy link
Author

Aricg commented Nov 28, 2019

@stsewd Can you be more specific?

If I trigger a build, say "latest" or "master" and there is a new ref tagged somewhere, read the docs lists all tags and branches internally and keeps track of that? so I could say only trigger only /latest/ (which maps to master) in my CI and new tags detected would automatically trigger /stable/ for me?

@no-response no-response bot removed the Needed: more information A reply from issue author is required label Nov 28, 2019
@Aricg
Copy link
Author

Aricg commented Nov 28, 2019

"it also triggers a build to latest if master has changed. Hope that answer your question."

This statement adds to my confusion, my experience is that this does not hold true.
When a build was triggered via curl, using a the old method:
"generic api integration"

curl -X POST -d "branches=${GERRIT_BRANCH}" -d "token=$RTD_TOKEN" "$RTD_BUILD_URL

this returned for example:

{"build_triggered":true,"project":"o-ran-sc-doc","versions":
["latest","master"]}

So the previous behavior was to build latest and master from a call with
branches=master

when we post via the v3 api.
lftools rtd project-build-trigger "$rtdproject" "$STREAM"

It actually respects the $STREAM variable and only builds "master"

Here is my patch that keeps /latest/ /master/ in sync:
https://gerrit.linuxfoundation.org/infra/c/releng/global-jjb/+/62314

I am trying to understand what I need to do to keep /stable/ in sync,

This is what I have so far
the api implementation does as you mentioned
POST /api/v3/projects/(string: project_slug)/versions/(string: version_slug)/builds/

STREAM is one of 'master' or 'branch'

  lftools rtd project-build-trigger "$rtdproject" "$STREAM"
  if [[ $STREAM == "master" ]]; then
    lftools rtd project-build-trigger "$rtdproject" latest
  else
    lftools rtd project-build-trigger "$rtdproject" stable
  fi

@stsewd
Copy link
Member

stsewd commented Dec 3, 2019

If I trigger a build, say "latest" or "master" and there is a new ref tagged somewhere, read the docs lists all tags and branches internally and keeps track of that? so I could say only trigger only /latest/ (which maps to master) in my CI and new tags detected would automatically trigger /stable/ for me?

When you trigger any build, before building the docs, we collect information about the repo, like branches and tags. If we detect a new tag or branch (and it's greater than the current stable, a build is triggered for the new stable). Or if the latest branch (master) changes, we trigger a new build to latest too.

Also, if you have set up the webhook to send the events when a tag or branch is pushed/created/deteled, rtd can update/build automatically stable and latest https://docs.readthedocs.io/en/stable/webhooks.html#github.

@stsewd
Copy link
Member

stsewd commented Dec 3, 2019

Ok, I think I understand better what you mean and what we are doing :D.

You were using the generic integration bc you are not using github, but a self hosted git server.
All the integrations receive the name of the branches/tags to build.

RTD can have more than one version linked to one name of a branch/tag. This is the case of LATEST and STABLE. The branch name master is linked to the version master and latest. The branch name 2.0 (for example) will be linked to the version stable and 2.0.

API v3 search for slug only (not for the name of the branch/tag), that's why it only triggers one build.

Both methods will still sync the versions when a build is triggered. And update stable. Looks like master/latest isn't updated when using apiv3.

I think we should update latest/master in the same place we do it for stable, and not update it only when it's received from a webhook.

@chrisinmtown
Copy link

Trying to follow @stsewd explanations. I guess that all changes on git branch "master" are exposed in RTD under the name "latest". Many teams use "master" branch as the development branch, so I think I follow. But what is "stable"? Naively I read that word as implying a version has passed some kind of validation. But I don't see how RTD can possibly know about any such thing.

@stsewd
Copy link
Member

stsewd commented Dec 3, 2019

@chrisinmtown you can read more about stable here https://docs.readthedocs.io/en/stable/versions.html

And yes, latest is an alias for master (but users can change that)

lfit-replication pushed a commit to lfit/releng-global-jjb that referenced this issue Dec 16, 2019
Allow docs release via jjb config
Changes the default landing page from /latest/ to /stable/

by default we se to /latest/ (a no-op)
And on release change to stable via jjb config.

read the docs, by design creates /latest/ and /stable/ landing points
for the user.

If read the docs sees a tag or a new branch, it creates a /stable/
directory, which follows the latest tag or if there is no tag, the
latest branch.

Related issue where I ask for clarification as to their default
behavior in this regards.
readthedocs/readthedocs.org#6415

ISSUE: RELENG-2549
Signed-off-by: Aric Gardner <[email protected]>
Change-Id: I33a8df14e68340ba268c953a471daa02ee6fe766
@stale
Copy link

stale bot commented Jan 17, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Jan 17, 2020
@Aricg
Copy link
Author

Aricg commented Jan 21, 2020

So I re-read the docs, and /stable/ is only created (and enabled automatically for that matter) if a tag is pushed, so I think the docs needs some clarification.

https://docs.readthedocs.io/en/stable/versions.html#tags-and-branches
"Read the Docs supports two workflows for versioning: based on tags or
branches. If you have at least one tag, tags will take preference over
branches when selecting the stable version."

But /stable/ will never get created unless you do push a tag. so "take preference" doesn't make sense in this case afaict, I can't see how stable will ever point to the head of a branch, or how to make /stable/ exist without having pushed a tag.

@stale stale bot removed the Status: stale Issue will be considered inactive soon label Jan 21, 2020
@stsewd stsewd added Needed: documentation Documentation is required and removed Support Support question labels Jan 22, 2020
@stale
Copy link

stale bot commented Mar 7, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Mar 7, 2020
@stsewd stsewd removed the Status: stale Issue will be considered inactive soon label Mar 9, 2020
@stale
Copy link

stale bot commented Apr 25, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Apr 25, 2020
@stale stale bot closed this as completed May 2, 2020
@stsewd stsewd added Accepted Accepted issue on our roadmap and removed Status: stale Issue will be considered inactive soon labels May 4, 2020
@stsewd stsewd reopened this May 4, 2020
@ssbarnea
Copy link

I think that I found a big flaw in the current logic and I have no idea how to address it. We created a latest tag which is a mobile tag used in parallel with normal versioned tags.

The side effect of this is that now the documentation no longer builds on main branch.

The only version enabled in RTD is named 'latest' and there are no options to configure it. Because it happens to be a tag with same name, we no longer build main.

Is there something we can do to keep building documentation from main branch while not removing the latest tag?

@stsewd
Copy link
Member

stsewd commented Jan 2, 2024

Is there something we can do to keep building documentation from main branch while not removing the latest tag?

You can activate the "main" version on RTD, or deactivate the latest tag.
If you deactivate the tag, you won't be able to build docs from that tag.

If you can link me to your RTD project, I can look into what exactly the solutions can be for your case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Needed: documentation Documentation is required
Projects
None yet
Development

No branches or pull requests

5 participants