Periodic job to update git submodules to latest release

[iranzo]

In Pelican-Elegant we're facing that the code pointed at this repo targets an old release instead of master branch which contains latest stable features.

This repo should automatically pull latest changes in submodules periodically (I can help setting up a bot for that with travis) and push them to the repo

[talha131]

There is this bot https://dependabot.com/submodules/

1. It's been acquired by Github
2. Free of charge
3. Update submodules for you.

If pelican team adds this bot, it will make our lives easier. We will not have to periodically open PR like these

#654

[avaris]

Will it be OK for all submodules? Feels like it will take away some control from the author(s).

Also, it's easy to update all submodules locally:

git submodule update --remote

PS: I do sometimes wish git had the ability to pin submodules to a branch as well, not just a commit.

[iranzo]

Well, right now, not updating is a problem for others as 'candidate' users, are getting an older version when checking out the repo which might contain failures or not be adapted to latest pelican.

[avaris]

I didn't mean "let's not update them... ever..." :). What I was trying to say is that this depends on (all) submodule authors. What's true for a submodule might not be true for another. Say an author might push experimental stuff to their branch but wants to keep this repo point to a stable version until it's ready.

[iranzo]

I know, but that means that 'master' is considered 'devel' for authors instead of new 'experimental' branch for that ;-) so pelican project team would need to decide, for me, 'latest' should be working on all repos (as I, by default, checkout latest)

In elegant, we do use 'next' for 'latest' and 'master' for releases. How many people 'cared' to reask to get updated repo pointers so far? that could give us an idea if people just follows that procedure or just, ignore it once it hits the repo (which would raise other concerns like compatibility check,etc)

[talha131]

@avaris

Will it be OK for all submodules? Feels like it will take away some control from the author(s).

and

What's true for a submodule might not be true for another. Say an author might push experimental stuff to their branch but wants to keep this repo point to a stable version until it's ready.

I see your point and whole heartedly agree.

The bot can be configured to update only selected themes. See docs here

And it can also be configured to auto merge specific updates.

So if you enable this bot, then we want Elegant to be auto updated and auto merged.

We are not proposing enabling it for all other themes and submodules unless their authors explicitly agree.

In the long run, it will result in a smaller backlog of open PRs.

---

Also, it's easy to update all submodules locally:
git submodule update --remote

We have no way of knowing the comfort level of users and their setup. We can't rely on the user to know he has to update the submodules, much less to know how to update.

The expectation is that the latest version of theme will work out of the box without user intervention.

[avaris]

I am OK with an opt-in solution, but the original message implied an all-in approach (at least, I got that impression).

We have no way of knowing the comfort level of users and their setup. We can't rely on the user to know he has to update the submodules, much less to know how to update.
The expectation is that the latest version of theme will work out of the box without user intervention.

This solves the initial clone but you can't escape a bit of git knowledge to keep that local clone up-to-date. This seems especially true for your theme: 3 4 releases in the last 7 days. You are busy :).

Updating submodules here will only change the command:

git pull --recurse-submodules

[talha131]

I am OK with an opt-in solution,

Thanks a lot.

but the original message implied an all-in approach (at least, I got that impression).

Sorry, I should have been clear. Obviously, we can't expect all theme developers to agree to autoupdates.

This solves the initial clone but you can't escape a bit of git knowledge to keep that local clone up-to-date.

Again, I agree. With static site generator, sooner or later user has to get his hand dirty. Still I think keeping Elegant submodules automatically updated is best,

1. User clones the themes repo and is test driving all the themes to pick one. He may not bother to update the modules unless he likes one.
   In this scenario he would be previewing an old outdated version
2. I have come across blogs that are using an old version of Elegant. Activity on the blog shows that the owner maintains the site regularly but for some reason do not update the theme.
   I can't comment on their setup but if submodule is updated then they are more likely to get the updated version. It will increase the chances
3. pelican-themes repository is much more popular than any other theme repository. I think it's a good idea if changes are published here too (via submodule update) for better visibility and attention.
4. No harm if auotomation if it does not affect other themes.

Finally, you have currently 47 open PR. You need some sort of automation to reduce the load.

We would greatly appreciate if dependabot or any other similar bot is integrated, that would keep our submodule updated.