[docs] [PATCH 1/2] scripts/run-docs-build: add for loop when publishing tags/branches


Quentin Schulz
 

Hi Nicolas,

On Thu, Mar 25, 2021 at 07:12:10PM +0100, Nicolas Dechesne wrote:
Use for loop to avoid repeating the same pattern over and over.

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
scripts/run-docs-build | 72 ++++++++++++++++--------------------------
1 file changed, 27 insertions(+), 45 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 79b1edc..e8e081c 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -33,17 +33,14 @@ make publish
mkdir $outputdir/bitbake/next
cp -r ./_build/final/* $outputdir/bitbake/next

-git checkout 1.48
-make clean
-make publish
-mkdir $outputdir/bitbake/1.48
-cp -r ./_build/final/* $outputdir/bitbake/1.48
-
-git checkout 1.46
-make clean
-make publish
-mkdir $outputdir/bitbake/1.46
-cp -r ./_build/final/* $outputdir/bitbake/1.46
+# stable branches
+for branch in 1.46 1.48; do
+ git checkout $branch
+ make clean
+ make publish
+ mkdir $outputdir/bitbake/$branch
+ cp -r ./_build/final/* $outputdir/bitbake/$branch
+done

# only sync bitbake folder for now. We need bitbake to be published first
# since the bitbake intersphinx index will be downloaded to build yocto-docs
@@ -69,40 +66,25 @@ make publish
mkdir $outputdir/next
cp -r ./_build/final/* $outputdir/next

-cd $ypdocs
-git checkout gatesgarth
-make clean
-make publish
-mkdir $outputdir/gatesgarth
-cp -r ./_build/final/* $outputdir/gatesgarth
-
-cd $ypdocs
-git checkout dunfell
-make clean
-make publish
-mkdir $outputdir/dunfell
-cp -r ./_build/final/* $outputdir/dunfell
-
-cd $ypdocs
-git checkout yocto-3.2.1
-make clean
-make publish
-mkdir $outputdir/3.2.1
-cp -r ./_build/final/* $outputdir/3.2.1
-
-cd $ypdocs
-git checkout yocto-3.2
-make clean
-make publish
-mkdir $outputdir/3.2
-cp -r ./_build/final/* $outputdir/3.2
-
-cd $ypdocs
-git checkout yocto-3.1.5
-make clean
-make publish
-mkdir $outputdir/3.1.5
-cp -r ./_build/final/* $outputdir/3.1.5
+# stable branches
+for branch in dunfell gatesgarth; do
+ cd $ypdocs
+ git checkout $branch
+ make clean
+ make publish
+ mkdir $outputdir/$branch
+ cp -r ./_build/final/* $outputdir/$branch
+done
+
+# Yocto Project releases/tags
+for tag in 3.1.5 3.2 3.2.1; do
What about using `git tag -l 3.2*` so that we don't need to maintain the
list of tags?

Or, maybe `git tag --contains <3.1.5 commit hash introducing sphinx doc>
--contains <3.2 commit hash introducing sphinx doc>` so that the
3.1.[56789] tags don't need to be added either?

Same mechanism can be used for bitbake git repo I guess.

Cheers,
Quentin


Nicolas Dechesne
 



On Fri, Mar 26, 2021 at 11:08 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Nicolas,

On Thu, Mar 25, 2021 at 07:12:10PM +0100, Nicolas Dechesne wrote:
> Use for loop to avoid repeating the same pattern over and over.
>
> Signed-off-by: Nicolas Dechesne <nicolas.dechesne@...>
> ---
>  scripts/run-docs-build | 72 ++++++++++++++++--------------------------
>  1 file changed, 27 insertions(+), 45 deletions(-)
>
> diff --git a/scripts/run-docs-build b/scripts/run-docs-build
> index 79b1edc..e8e081c 100755
> --- a/scripts/run-docs-build
> +++ b/scripts/run-docs-build
> @@ -33,17 +33,14 @@ make publish
>  mkdir $outputdir/bitbake/next
>  cp -r ./_build/final/* $outputdir/bitbake/next

> -git checkout 1.48
> -make clean
> -make publish
> -mkdir $outputdir/bitbake/1.48
> -cp -r ./_build/final/* $outputdir/bitbake/1.48
> -
> -git checkout 1.46
> -make clean
> -make publish
> -mkdir $outputdir/bitbake/1.46
> -cp -r ./_build/final/* $outputdir/bitbake/1.46
> +# stable branches
> +for branch in 1.46 1.48; do
> +    git checkout $branch
> +    make clean
> +    make publish
> +    mkdir $outputdir/bitbake/$branch
> +    cp -r ./_build/final/* $outputdir/bitbake/$branch
> +done

>  # only sync bitbake folder for now. We need bitbake to be published first
>  # since the bitbake intersphinx index will be downloaded to build yocto-docs
> @@ -69,40 +66,25 @@ make publish
>  mkdir $outputdir/next
>  cp -r ./_build/final/* $outputdir/next

> -cd $ypdocs
> -git checkout gatesgarth
> -make clean
> -make publish
> -mkdir $outputdir/gatesgarth
> -cp -r ./_build/final/* $outputdir/gatesgarth
> -
> -cd $ypdocs
> -git checkout dunfell
> -make clean
> -make publish
> -mkdir $outputdir/dunfell
> -cp -r ./_build/final/* $outputdir/dunfell
> -
> -cd $ypdocs
> -git checkout yocto-3.2.1
> -make clean
> -make publish
> -mkdir $outputdir/3.2.1
> -cp -r ./_build/final/* $outputdir/3.2.1
> -
> -cd $ypdocs
> -git checkout yocto-3.2
> -make clean
> -make publish
> -mkdir $outputdir/3.2
> -cp -r ./_build/final/* $outputdir/3.2
> -
> -cd $ypdocs
> -git checkout yocto-3.1.5
> -make clean
> -make publish
> -mkdir $outputdir/3.1.5
> -cp -r ./_build/final/* $outputdir/3.1.5
> +# stable branches
> +for branch in dunfell gatesgarth; do
> +    cd $ypdocs
> +    git checkout $branch
> +    make clean
> +    make publish
> +    mkdir $outputdir/$branch
> +    cp -r ./_build/final/* $outputdir/$branch
> +done
> +
> +# Yocto Project releases/tags
> +for tag in 3.1.5 3.2 3.2.1; do

What about using `git tag -l 3.2*` so that we don't need to maintain the
list of tags?

Or, maybe `git tag --contains <3.1.5 commit hash introducing sphinx doc>
--contains <3.2 commit hash introducing sphinx doc>` so that the
3.1.[56789] tags don't need to be added either?

yes, I thought about that too.. I wanted to get a quick fix first to publish 3.1.6 and 3.2.2 which were missing.. 
on the other hand, we have a larger issue with this. The 'release' information is needed here , but it's also needed on the website (downloads) and it's needed in the switchers.js as well... 
So we probably want to take a high level view of the problem. Michael created https://bugzilla.yoctoproject.org/show_bug.cgi?id=14330 to let us think about it.

my idea would be a publish/maintain a yaml file that would represent the database of all our releases and docs, which would be maintained/updated by the release manager, it would include all information we need to build and publish the docs, update the 'download' page on the website, ... 

up until now, we have been using:

i think we need a few improvements to that.. 



Same mechanism can be used for bitbake git repo I guess.

Cheers,
Quentin