[WIP] Quick build command

[joerick]

This command pushes a stash of the repo to the origin remote, to avoid
needing to push loads of tiny commits while you're crafting the perfect
build config.

The stash push will trigger an Appveyor and Travis build, so the build
can be checked before committing the change.

[joerick]

Open to feedback on this! currently I'm thinking the interface isn't quite right, i think it should be more like a command quick-build not --quick-build but I can't figure out how to make argparse do that!!

[YannickJadoul]

Hmmm, I don't have a strong opinion about it, but that's probably mainly because I haven't used it (and since I kept committing and force pushing to specific travis/appveyor branches anyway, when debugging, but maybe this ís indeed cleaner). The main problem seems that if you quickly do this one after the other, you'll end up overwriting the previous stashed 'temporary commit' on the remote branch, and Travis CI/AppVeyor will crash in the jobs that haven't started yet, because that commit is now removed from the remote.

Have you looked at https://stackoverflow.com/questions/4575747/get-selected-subcommand-with-argparse, for the subcommands? If I can find some time, I'd be interested enough to see if I can play around with that a bit :-)

[altendky]

argparse has subparsers but... maybe click? But, within argparse, here's a thing I have.

https://gist.github.com/altendky/6a085be24502f3e2bce915fcf1db298d#file-create_venv-py-L404-L410

    rm_parser = subparsers.add_parser('rm', description='Remove the venv')
    rm_parser.add_argument(
        '--ignore-missing',
        action='store_true',
        help='Do not raise an error if no venv is present',
    )
    rm_parser.set_defaults(func=rm)

Particularly note the last line, that's how I set the function I want called to handle that subparser. You could use an enumeration or string or whatever else if you wanted dispatch based on an if or such (not recommending that though). Then I strip out ounc from the args and pass everything else on to the func.

But yeah, click...

Also, I'm not too sure about a bunch of temporary funny business being great. Builds with corresponding commits missing sounds confusing.

[joerick]

Thanks for the tips, that set_defaults thing might be useful.

Also, I'm not too sure about a bunch of temporary funny business being great. Builds with corresponding commits missing sounds confusing.

Yeah the temporary commit is pretty core to this idea, since we're basically pushing a stash.

But your comment makes me think there could be another approach where a branch is set up that just contains test builds - the diffs would be nonsense but at least there would be a record of what code did each build.

[altendky]

I more meant that if I want to isolate messy exploratory commits... I'll just make a branch myself. :] But I'm sure other people would be interested in this.

[joerick]

Closing due to inactivity.

on reflection, this is a neat feature, but it would be better as a git alias or something.

[YannickJadoul]

@joerick If you figure something out, might still be nice to add to the docs?