[TKLDev] Auto updates to common? (and perhaps other parts?)

[JedMeister]

Thinking aloud ...

Perhaps it would be a good idea to make common auto-update (from GitHub)?

Probably need to check branch first (don't want to mess with people who are hacking the code)...

Particularly useful while development is happening?!

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[DocCyblade]

Great idea! I don't think that would be too hard. Maybe hook into the make script so that before a make it checks to make sure it's on master is checked out then do a pull. Or just a script to do just that "tkldev-common-update.sh" I was thinking of doing that my self anyway as I found that a few times I was not working with the latest commit from common.

[l-arnold]

I think you could do a Git Clone to your Common Folder inside TKLDEV. Could actually have that folder be a clone to your Branch rather than normal common.

Scripts etc would of course be better. We were doing updates to (I belileve it was Common) a few weeks ago in that manner and it worked well.

Jeremy had the method for that one. At the time it involved the following:
git clone -b jessie-apache-tweak https://github.com/JedMeister/common.git

Might pull your own variation on Common instead (at least for now). I don't know all the detail here though.

[JedMeister]

@DocCyblade

Maybe hook into the make script so that before a make it checks to make sure it's on master is checked out then do a pull.

I don't think that is a good idea as you may be hacking in common and that might cause some unexpected issues. IMO the script needs to work in such a way that it doesn't get in the way even if you know nothing about it...

Or just a script to do just that "tkldev-common-update.sh"

That was more what I was thinking (although probably something in /usr/local/bin). And a cron job that runs it every day (or whenever)...

But IMO if this is automated then it needs a fair bit of thought as it needs to account for numerous possibilities and not interfere and/or break anything:

• not following the git flow and has uncommitted changes in the master branch
• following the gitflow but have uncommitted changes in their dev branch
• are currently building a server
• and so on...

So it would need to:

• check that a build job isn't running
• check what branch common is on
• stash any uncommitted changes on the current branch; or perhaps it's better to auto create a new branch if it's on master and do an auto commit?
• checkout the turnkey master branch (and configure it to do a fetch from turnkey's repo if isn't already, e.g. if someone has just cloned their own fork)
• do a git pull (git fetch & git merge) of turnkey master
• revert to original branch & auto merge - so long as there are no conflicts (git merge --abort might be useful, AFAIK it will only merge if there are no conflicts... Needs more investigation)
• let the user know that it has updated and/or if there are conflicts that need resolution...

The little script I use (for all TurnKey GitHub code updates) actually runs git pull. IMO it would probably be more efficient to use octohub to check the GitHub API for recent commits rather than actually running git pull straight up. Although TBH I haven't checked the API to see what is available for doing this...

[JedMeister]

I really like this idea but ATM it is not super important... Hence the new 'wishlist' tag 😄

[l-arnold]

General Question on Common, Core and TKLDEV.
I've been running a TKLDEV set I built quite a while ago now. I believe it pulled full common and core in TKLDEV Setup.
Question is: Should I be doing anything more than "apt-get update" to keep the system up to date.

I worry that my working systems may stop working when updates to Common and Core actually hit my system again. (not really worry, but have some concern).

[JedMeister]

Your working system won't stop working assuming that what you have now works fine... But your files will be out of sync with the current TurnKey repo (you will be missing all the latest changes). I recommend that you maintain your own branch of common (or any other app that you wish to work on), plus have an up to date version (from TurnKey) as well. I actually have about 5 branches of common on my system! 😄

How I have mine configured is that I track TurnKey master (on GitHub; which is a remote that I named 'upstream') with my local master. I then have my other branches, these track my own GitHub (a remote called 'origin').

If you want to set yours up like mine so you can save your known working branch that you have now but also have the latest from TurnKey please let me know. Perhaps I could do a blog post on it as it's certainly relevant to TurnKey...

[DocCyblade]

A write up would be good! I have a script I use to setup my TKLDev VM.

It assumes you have forked common on your own, and have an up to date pure master branch. As a rule of thumb or best practice I never mess with the master branch of a forked repo. Just time to time merge upstream master to mine, them merge my master with any branch I have that I am working on.

My script just changes the remote origin from turnkeys repo to my own then setup remote called upstream like you said that points to turnkey.

You could just rename the remote origin to upstream then add another remote as origin pointing to your own fork.

I'll post it if you want.

[JedMeister]

I think it would make a great blog post. And I think that the way you do it is essentially the same as I do. To spell out that process would be a really useful I think. I'll check with Alon and Liraz about getting you to do a guest blog post if you're interested?

Also as for automation (and future ideas for handy scripts); if you have octohub installed (and configured with a valid github auth token) you can just clone the TKL repo then include creation of your fork and new branch as part of that process

[DocCyblade]

octohub, nice little tool! That should be in the tkldev tool chain!

As for blog post, that would be groovy. Let me know the specifics of what you would like and I'll put on the docket of things to do :-)

[JedMeister]

Yeah Octohub is cool. I'm not much of a python programmer so I usually use the commandline/bash bit and team it with jq (because it outputs JSON) and it's awesome!

When I did all the Apache config updates for all the appliances I wrote a script which used Octohub to clone all the TKL-apps repos; search through to see whether they had apache config that needed update; where they did fork the code; create a new branch, make the changes commit and push back to my github. I originally tried to get it to issue the pull requests too (which theoretically should be possible) but i couldn't get it to work. I didn't put too much time into it though as I figured doing that last step manually and making sure that I hadn't missed something was a good diea...

Anyway I'll be speaking with Alon later today (my time) so will let know ASAP.