Go library for interacting with CircleCI

panic: interface conversion: interface {} is string, not *string [recovered]
panic: interface conversion: interface {} is string, not *string
github.com/jszwedko/go-circleci/circleci.go:756

When I'm trying to list all branches in a project (project.Branches), I'm getting the string which looks like this:

release%2F0%2E1%2E0

IMHO, the output should be unescaped (maybe by the url.QueryUnescape() function?)

FeatureFlags is defined as map[string]bool But in reality they are sometimes null too

 "feature_flags" : {
   "trusty-beta" : true,
   "osx" : false,
   "set-github-status" : true,
   "build-prs-only" : false,
   "fleet" : null,
   "build-fork-prs" : false,
   "autocancel-builds" : false,
   "junit" : true
 },

What Happpened

I called an api endpoint like so (psuedo-code)

circleci.Client{Token: circleToken}.ListProjects()

and got this error message

401: You must log in first

What I Was Expecting

When I call an api endpoint without being authorized, I get an error message like this

401: You must log in first. You can log in via ...

The request body for parametrized builds expects the body contents to be in the format:

{  "build_parameters": {
      "parameter_name": "parameter_value",
},

But currently just the contents inside the build_parameters key is sent, so the values aren't actually used.

I've updated the unit test, and tested this change on a project locally using the CIRCLE_JOB parameter to trigger a specific job and with these changes included the correct job is now triggered.

Problem

When triggering a build, optional parameters can be passed to override or add environment variables to that job:

https://circleci.com/docs/parameterized-builds/

Currently the library doesn't support doing this (Unless I completely missed it 😳)

Solution

I though about modifying the Build method to taken an optional (Can be nil) body but it changes the interface that some people may be relying on and as there's currently no versioning in the app could end up breaking peoples apps if they pull down the latest version.

Opted for a separate method ParameterizedBuild that essentially has an extra parameter for a struct that's Marshalled into a JSON string and posted to the trigger build endpoint.

Hey there!

Great work on the library, we're using it in one of our projects and it would be great if you tagged the repo so we had a version number when adding the package as a dep in our app!

It is possible to add more than build_parameters to a build, for example, you can add revision

Adding a new method, a bit more generic and keep to old ones to not break the API

I believe it would also solve, at least partially, #26

@jszwedko looks like https://circleci.com/docs/api/v1-reference/#new-build supports building a specific revision or tag. Do you have plans to support it? If so, would you be happy if contribute a patch, such as:

func (c *Client) Build(account, repo, branch, revision, tag string) (*Build, error) {
    ....
}

This will be a breaking change, unless you want me to introduce a new method?

When running circle-cli projects I receive an error message similar to parsing time "null" as ""2006-01-02T15:04:05Z07:00"": cannot parse "null" as """

http://stackoverflow.com/questions/26684752/json-decode-cannot-parse-timestamp-in-json-into-go-struct explains that you need to make pointer to *time.Time to handle null dates to become nil.

This PR changes all time.Time -> *time.Time

$ make lint
package golang.org/x/tools/go/gcimporter: cannot find package "golang.org/x/tools/go/gcimporter" in any of:
        /usr/local/Cellar/go/1.7.3/libexec/src/golang.org/x/tools/go/gcimporter (from $GOROOT)
        /Users/patrick/go/src/golang.org/x/tools/go/gcimporter (from $GOPATH)

In doing some work with the CircleCI API I got a suggestion that I look at v2 of the API. It is not yet released but some of the pre-release documentation is https://github.com/CircleCI-Public/api-preview-docs. Specifically, https://github.com/CircleCI-Public/api-preview-docs/blob/master/docs/api-changes.md holds the definition for the /workflow endpoint.

This change adds support for v2 of the API by initially adding the ability to fetch details for a specific workflow and all the jobs in that workflow. From there you can fall back to the v1 api to get the full details for a specific job.

I'm opening this PR for comments on the approach. Is this useful work? If it is, maybe it could be merged in to a v2 tag or something for further work before landing in master, since the API is still in pre-release mode and will likely change.

Thanks!

Here's some sample code that exercises the new functions defined: https://gist.github.com/maplebed/d9cb97961448dc02a641200b089e2f19

Hi there! There's a new API that's still in beta for triggering builds: https://circleci.com/docs/api/v1-reference/#new-project-build The old trigger build API is not compatible with Circle 2.1, so this new API is the only way to trigger builds for those on the new version.

I'm happy to take this on - are you accepting PRs? Thanks!

Version Control System (:vcs-type)

New with v1.1 of the api, for endpoints under /project you will now need to tell CircleCI what version control system type your project uses. Current choices are ‘github’ or ‘bitbucket’.