[arch-releng] archiso: also putting the hour in version string

[Dieter Plaetinck]

On Wed, 17 Aug 2011 23:38:55 -0300
Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> wrote:

> On 08/15/2011 02:14 PM, Dieter Plaetinck wrote:
> > On Mon, 15 Aug 2011 01:43:49 -0300
> > Gerardo Exequiel Pozzi<vmlinuz386 at yahoo.com.ar>  wrote:
> >
> >> On 08/14/2011 08:13 AM, Dieter Plaetinck wrote:
> >>> Hi,
> >>> I would like to run multiple builds per day. For this I would
> >>> like to also put the hour of building in the iso filenames.
> >>>
> >>>
> >>> something like:
> >>>
> >>> diff --git a/configs/releng/build.sh b/configs/releng/build.sh
> >>> index 1aa80fd..7fce685 100755
> >>> --- a/configs/releng/build.sh
> >>> +++ b/configs/releng/build.sh
> >>> @@ -4,7 +4,7 @@ set -e -u
> >>>
> >>>    name=archlinux
> >>>    iso_label="ARCH_$(date +%Y%m)"
> >>> -version=$(date +%Y.%m.%d)
> >>> +version=$(date +%Y.%m.%d.%H)
> >>>    install_dir=arch
> >>>    arch=$(uname -m)
> >>>    work_dir=work
> >>>
> >>>
> >>>
> >>> Or, maybe this is too releng-specific (i.e. most people who run
> >>> archiso probably prefer $(date +%Y.%m.%d), in which case: can you
> >>> give archiso a flag so that I can control the version as a
> >>> parameter?
> >>>
> >>> ./build.sh all_iso_single 2011.08.14.12
> >>> ./build.sh all_iso_dual 2011.08.14.12
> >>> ./build.sh all_iso_dual 2011.08.14-lets-try-some-new-code
> >>>
> >>> passing it as a flag would also be more robust.  Things could go
> >>> wrong (I think?) if the all_iso_single runs at 23:45 of one day
> >>> and all_iso_dual runs at 00:15 the next morning.
> >> Do not worry about this. You guess about LABEL? Not an issue,
> >> LABEL for dual is also generated at build time (not read from
> >> "single" work). Also you can have a 201112 and 201201. :P
> > That's the point. If I build multiple isos after each other (like
> > first single isos, then duals) I want all of them to have the same
> > version.
> >
> >> what do you think about via env var?
> > It's possible but I don't like it.  If we already have option
> > passing through cmdline args, I think we should pass new options
> > that way too. Also it makes it very clear to the user what you can
> > do (implenting ./build.sh -h which would show all flags with
> > explanation) while you're at it, probably a good idea to use getopt
> > and make verbosity also controllable with a flag. (now my code
> > needs to call sed on your script..)
> >
> > Dieter
> >
> 
> How about this?
> 
> usage ./build.sh [options] command <command options>
> 
>   General options:
>      -N <iso_name>      Set an iso filename (prefix)
>                          Default: archlinux
>      -V <iso_version>   Set an iso version (in filename)
>                          Default: 2011.08.17
>      -L <iso_label>     Set an iso label (disk label)
>                          Default: ARCH_201108
>      -D <install_dir>   Set an install_dir (directory inside iso)
>                          Default: arch
>      -w <work_dir>      Set the working directory
>                          Default: work
>      -o <out_dir>       Set the output directory
>                          Default out
>      -v                 Enable verbose output
>      -h                 This help message
> 
>   Commands:
>     build <mode> <type>
>        Build selected .iso by <mode> and <type>
>     purge <mode>
>        Clean working directory except iso/ directory of build <mode>
>     clean <mode>
>        Clean working directory and .iso file in output directory of 
> build <mode>
> 
>   Command options:
> <mode> Valid values 'single' or 'dual'
> <type> Valid values 'net', 'core' or 'all'
> 
> 

looks perfect