add http publishing task

[lalloni]

This little patch adds an "http" task for publishing built artifacts using http PUT.

Tested/implemented for publishing to internal Nexus server used as internal artifact repository, but should be usable for any http server which accepts PUT requests (including any webdav server such as svn, alfresco or sharepoint) .

Allows to specify a template for building the url used for putting every file, as well as the http basic auth credentials to be used for the requests (should be set in .goxc.local.json).

Exposes FileInfo and TaskParams for use in the url template.

Sample .goxc.json section:

{
    "ConfigVersion": "0.9",
    "TaskSettings": {
        "http": {
            "url-template": "http://172.17.0.2:8081/content/repositories/releases/dearin/gostore/{{ .TaskParams.Settings.GetFullVersionName }}/{{ .FileInfo.Name }}"
        }
    }
}

Sample .goxc.local.json section:

{
    "ConfigVersion": "0.9",
    "TaskSettings": {
        "http": {
            "username": "admin",
            "password": "admin123"
        }
    }
}

[laher]

Hi there, thanks very much for the pull request. I'd love to acccept it, but first I'd like to consider the task name 'http' and the defaults (e.g. PUT and Basic-Auth).

Unfortunately I'm about to leave for a holiday for a week, and I can't make/test a decision right now... I'll just leave you with some thoughts for the time being.

• I guess basic-auth and PUT are sensible defaults. These values are also used by the 'bintray' task. Out of interest, what service are you uploading to?
• I think I prefer 'publish-http' as a task name, which I'd add to an alias called 'publish'. That way it's clear what it's doing, and users could still use a short name 'publish' or 'pub'. When you use goxc pub, it would conditionally call one of 'publish-http', 'publish-ssh', 'bintray', etc ... , depending on task settings.

What do you think?

[lalloni]

We're publishing to an internal nexus deployment. Although it should work as is for many other compatible http or webdav servers such as alfresco, svn, apache, etc.

+1 on publish-* & publish alias! That's exactly what I thought at first, but then, bintray task is called bintray... and I did not want to bork the "standard", so my PR was accepted quickly ;)

Of course some other variations can be planned, specially in the authn side, but I believe using basic-auth is ok for a version 1 of the task, and is what I see most in other tools such as maven, sbt, etc. (Yes, I come from javaland).

From a design standpoint, what I really don't like is exposing fileinfo and taskparams to the template producing an unwanted coupling... I thought of creating a map[string]string with relevant data for the task (but then: what is relevant data for the task?) and then use that as the context for the template expansion, but I wanted to discuss it a little first, given my little experience with golang & the goxc project (again, I find it ok as is for a first version).

EDIT: fix wrong link to nexus site

[laher]

OK sweet. Nexus integration is a good thing.

• Yes, 'bintray' is a poor name. (I'll eventually rename it, add more bintray-related tasks, and keep bintray as an alias for a group of bintray-related operations)
• Yes, basic-auth is good for now. I also came from javaland, and escaped only recently. (Just kidding, JVM has its merits, especially Scala).
• Good point re the template params. In other tasks (e.g. the downloads page), I have created a struct with some specifics like AppName, Version, FileName(s), and then usually a configurable 'templateExtraVars' map. Not sure if you'd need that, but it adds some flexibility.

Incidentally I just checked the github release api and it's going to be more similar to the bintray task (adding versions etc), so I'll do that separately. All good.

OK, got to go. Cheers

[lalloni]

• Task renamed to "publish-http"
• Decoupled url template context from goxc "internal" structures by using a map of values

[laher]

Thanks so much, sorry for not getting back sooner.

The changes look good and I trust your workmanship.

I just added you to the project. Would you like to merge it in yourself? It's a common policy for good pull-requests to be recognised in this way. Good work, my friend

[lalloni]

Thanks to you!

I've had a pending small refinement in my local repo which explicits the default case for failing the publishing task if a file already exists in the remote http server (default behavior in other tools).

Please check it out, and if the patch still looks good to you, then I'd be pleased to merge it.

[lalloni]

Travis CI build failure seems unrelated... so, I'm merging this anyway, since it works fine locally.