Regularity of backups

[dazsmith]

Thanks for a great program!

I wanted to be able to schedule regular backups, but some projects need to be backed up at different regularities than others. So I forked and added the concept of regularity to your code. Now each project has associated with it a list of regularities. If the regularity (passed as argument -r) matches one in the list for the project, then it is exported. You can see the details at https://github.com/dazsmith/gitlab-project-export/commits/master.

Should I submit a pull request?

[rvojcik]

Hi dazsmith,

thank you for your contribution. It would be great if program behave like before when you don't specify regularity option. The reason is backward compatibility.

For example I use this program in our production backup solution and I have to do some seriouse changes to implement regularity.

[dazsmith]

Thanks, rvojcik.

Sorry I did not think of backward compatibility. I am quite new to this and had not considered it.

I can certainly make the command line argument backward compatible, by just having the default regularity be "always" which makes every listed repository be backed up. But it's not so easy to make the config files compatible. Here are a few ways to do that.

Option 1: Different versions of config file format, the python script can read both. If it encounters an original config file then it just exports all the repositories listed, regardless of the regularity passed as argument of -r. If it encounters the new type of config file then it can action the regularity. The disadvantages of this approach are (i) that the old version of the script will not be forwards compatible with the new config file and (ii) having more than one config file format adds complexity to all future development.

Option 2: Config file the same as the original specification, but add a new section

regularity:
  rvojcik/example-project:
    [year, month, week, day]
  rvojcik/group/*:
    [year]

This is somewhat cumbersome because, when one creates a new GitLab project that needs to be regularly exported, one must add its details in TWO places in the config file.

Option 3: Similar to option 2, but the config file's new section has the format

regularity:
  year:
    - rvojcik/example-project
    - rvojcik/group/*
  month:
    - rvojcik/example-project
  week:
    - rvojcik/example-project
  day:
    - rvojcik/example-project

This means potentially adding each new project in many more places, but otherwise has advantages and disadvantages similar to option 2.

So I suppose it comes down to option 1 for easier use or option 2/3 for easier development. But if you were ever happy to break backwards compatibility with the original config file format, then there is much less disadvantage in option 1. On this basis, to me, option 1 is far preferable.

What do you think? Is there another option I haven't spotted?

[fitzg2]

Use cron

[rvojcik]

I'm closing this. Not bad idea but if the project acts like a daemon. Now it has to by executed from cron, so it's much easier to use cron and different configs for different jobs.