Add automatically scheduled theme updates #259
Comments
Maybe something like this? git clone --depth 1 https://github.com/spf13/hugoThemes
git submodule update --init --remote
git commit -am "updated themes at $(date +"%Y-%m-%d %H:%M")"
git push Travis CI now has corn job support. It can run daily. It will pull all latest changes and push it to the repo. That should trigger a build. |
I consider my theme master "mostly stable", and use SemVer and Git tags with a changelog generator whenever I have noteworthy updates. I've seen some others following the same approach. |
Potential design approach: https://blog.readme.io/writing-a-cron-job-microservice-with-serverless-and-aws-lambda/ |
Then we can just create a webhook in Netlify. See #259
This can be implemented with CircleCI. Just let me know. |
@orf posted about Dependabot in another pull request This is a free service that has been acquired by GitHub and it provides a way to create pull requests when submodules are updated (once a day or once a week). This is not a fully automatic theme update since in the end a human needs to review and merge these Pull Requests. It would still save time though since it would remove the need to maintain a local clone with every theme in the repo. Anyway maybe we should investigate if it's possible to use Dependabot in this repo. |
I've been testing Dependabot using my fork of this repo. Submodules can be updated on a daily or weekly basis. One "issue" I see is that Dependabot creates a new pull request for each updated submodule. This can get quite noise after a while. The grouping of pull requests is still an open feature request. I suggest to schedule the updates weekly. Furthermore, Dependabot allows you to auto-merge pull request if they match certain rules (i.e. only merge security updates etc.). Dependabots pull requests don't need to be approved or reviewed. Having them auto-merged means @onedrawingperday and I don't have to merge them manually. But I still have to get that working. |
Update: Automerge works but is not performed because Dependabot detected that we use Netlify as CI-service. This can be deactivated in the config file found at A while ago Netlify started to charge for build minutes. They granted us a special open-source plan for pricing that likely excludes us and no credit cards are deposited. But it is still inefficient to rebuild the theme site with each updated theme / pull request. |
Perhaps it could be modified to only build the site with a single theme (the one being updated) in pull requests? |
Are you referring to the build script for the Hugo theme site? |
Yes, in a pull request you could build the hugo theme site with a single theme, the one being updated. That would be a lot faster and give you reasonable confidence that merging this won't suddenly break the entire build. |
Right now the build script does not support "incremental" builds. Unfortunately it's all or nothing that gets rebuild. Netlify already caches the submodules (themes) but the Hugo theme site still gets rebuild in its entirety. |
Oh I see... thanks for looking into Dependabot @digitalcraftsman A PR per updated submodule is not ideal. It will clutter the repo’s history and waste Netlify’s Open Source plan. It’s a shame that Dependabot cannot include all updates in a single PR. |
I have some great news. On my fork of the Hugo themes I was able to update all theme submodules with GitHub Actions. Best of all the GitHub Actions bot can be scheduled to run automatically with POSIX cron syntax:
Here is the full log of the automated themes updated on my fork. Here is the commit with the automated Themes Update. Here are the contents of my
Notes:
I think that if we enable this in the repo it will make our lives much easier. |
@digitalcraftsman So that is the file to you may want to amend. |
With commit 6e48377 I scheduled the Theme Updates to run: If everything I've done is fine, then this issue can be closed. |
Themes were updated automatically and on schedule with commit da06a61 🚀 This issue is resolved. |
The current approach requires a manual update of the submodules that reference the themes. A cron job or a similar tool could alternatively update the theme list automatically in a predefined interval, e.g. once a day.
This way theme maintainers aren't dependent on the current, unplanned (but still regular) update cycle.
As suggested by @MunifTanjim in this comment.
The text was updated successfully, but these errors were encountered: