Add gh-action for updating dropdown menus
Closed this issue · 12 comments
xref:
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Checkout submodules
run: git submodule update --init --recursivegh-action cron https://docs.getnacelle.com/deployment/scheduled-builds-github-actions.html#configure-the-schedule
also see this cron gh-action
https://github.com/MathewBiddle/ioos_by_the_numbers/blob/main/.github/workflows/metrics.yml
Did it manually. Steps below:
- Updated the
topnav_ioos.ymlon thenavbarsbranch. - Committed those changes to the
navbarsbranch (via PR and merge). - Updated the submodule connections in the
gh-pagesbranch here, using the git steps below.
> git submodule update --remote
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 2.42 KiB | 248.00 KiB/s, done.
From https://github.com/ioos/documentation-theme-jekyll
248d4c8..3a0e9ee navbars -> origin/navbars
Submodule path '_data/navbars_theme': checked out '3a0e9eecda1a82dd57e5a6cffba1f80411087141'
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 2.42 KiB | 191.00 KiB/s, done.
From https://github.com/ioos/documentation-theme-jekyll
248d4c8..3a0e9ee navbars -> origin/navbars
> git status
On branch gh-pages
Your branch is up to date with 'origin/gh-pages'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: _data/navbars_theme (new commits)
no changes added to commit (use "git add" and/or "git commit -a")
> git diff
diff --git a/_data/navbars_theme b/_data/navbars_theme
index 248d4c8..3a0e9ee 160000
--- a/_data/navbars_theme
+++ b/_data/navbars_theme
@@ -1 +1 @@
-Subproject commit 248d4c8ac0091d4f36b92ee39e45903e9fcd6d8e
+Subproject commit 3a0e9eecda1a82dd57e5a6cffba1f80411087141
> git commit -am "update theme"
[gh-pages ae330ed] update theme
1 file changed, 1 insertion(+), 1 deletion(-)
> git push origin gh-pages
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 328 bytes | 328.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote:
remote: GitHub found 16 vulnerabilities on ioos/mbon-docs's default branch (10 high, 5 moderate, 1 low). To find out more, visit:
remote: https://github.com/ioos/mbon-docs/security/dependabot
remote:
To https://github.com/ioos/mbon-docs.git
ef7e22b..ae330ed gh-pages -> gh-pages@ocefpaf @mwengren mind taking a look at this gh-action?
https://github.com/ioos/mbon-docs/blob/gh-pages/.github/workflows/sync_theme.yml
The action is supposed to to the following tasks:
- Run every day at noon.
- Checkout the current repo
gh-pagesbranch. - Check for updates in the theme submodules
- Show the differences.
- Commit the changes.
- Push changes to
gh-pages.
I am hopeful that we can simply copy this yml file to all of our ioos.github.io documentation sites and this will keep them up to date with our theme (if it changes).
seems to have worked: https://github.com/ioos/mbon-docs/actions/runs/4116540943/jobs/7106714685
In testing I changed the time so I could see the cron job run automatically.
Cool, I had no idea we could do this with the checkout GHA.
Everything looks good to me. How are you following possible errors? Did you set GH to send you an email or are you watching the notifications?
PS: Do you know about crontab guru for cronjob checks?
Thanks for the crontab guru reference! Super helpful.
How are you following possible errors?
Just watching the notifications for errors. Should probably do more error checking, but I wanted to get it working first.
The action ran successfully, but wasn't doing anything. Notice [1]. nothing to commit, working tree clean Essentially I am not pulling over the most recent version of each of the submodules.
Now, I'm trying to figure out how I pull over the most recent versions of the submodules. However, I'm running into an issue when git submodule update --remote because it can't find _data/navbars_theme. See [2].
According to [3], git pull --recurse-submodules might do the trick.
[1] - https://github.com/ioos/mbon-docs/actions/runs/4126722795/jobs/7129013459#step:3:13
[2] - https://github.com/ioos/mbon-docs/actions/runs/4135852464/jobs/7148885809#step:3:1
[3] - https://stackoverflow.com/questions/40987847/unable-to-find-current-origin-master-revision-in-submodule-path
@MathewBiddle Based on what you discovered for the GHA config, was the git submodule update --init step the missing piece? Would that have resolved this issue: ioos/ioos-documentation-jekyll-skeleton#4?
If so, we should probably update the HOWTO docs with that line: https://ioos.github.io/ioos-documentation-jekyll-skeleton/howto.html#a-note-on-submodules. I can look at that once I refresh my memory a bit.
Yes. After this commit the GHA worked correctly. d7520e5
You can see how it checked out the correct branch, then fast forwarded that branch to the most up to date (not sure if that was the update or the merge piece though):
https://github.com/ioos/mbon-docs/actions/runs/4137189385/jobs/7152041754#step:3:1
I think I no longer need these lines, however.
mbon-docs/.github/workflows/sync_theme.yml
Lines 30 to 34 in d8d1287
Let me do some more tinkering to slim this GHA down.
Okay, so it's
git submodule update --init
This sets up the submodules with all the references defined in the .gitmodules file. But, it pulls over the last committed version that was used in this repo.
To update the submodules (once the references are established as above), run:
git submodule update --remote --merge
--remote tells git to update submodules without having to git pull for each of them.
One thing that helped me in deciphering where I was running into issues was using git submodule status and checking what branch was referenced (note remotes/origin/navbars - before this was pinned to a specific commit, eg 3a0e9ee). If it was pinned to a specific commit, the submodule wouldn't see any changes and thus nothing would happen.
+a2e22c750ad4056164fbf4ae6eeca2aa92173aa5 _data/navbars_theme (remotes/origin/navbars)
6674af5f1b065d2d24e358472f428f864b023c60 theme (heads/master)versus
3a0e9eecda1a82dd57e5a6cffba1f80411087141 _data/navbars_theme (3a0e9ee)
6674af5f1b065d2d24e358472f428f864b023c60 theme (heads/master)The most recent GHA should be clear about what is happening https://github.com/ioos/mbon-docs/actions/runs/4177721923/workflow
Yes, this all looks familiar now. The git submodule set-branch command shouldn't be needed and it reads instead from .gitmodules when --init is called.
So we need to keep the --merge flag as well? Earlier versions of your GHA didn't include it. So basically this should go in the HOWTO?
git submodule update --init
git submodule update --remote --merge
To pull in changes. With an optional
git submodule status
to confirm everything's working as it should?
correct.
done in e5a8dda