cvbarros/go-teamcity

Golang client for TeamCity REST API

go-teamcity's Issues

Enable Update for VCS Roots

VcsRootService has no Update capability.
This issue is to add this feature so VCS Roots can also be updated.

Upgrade supported TeamCity to 2019.x

This issue is to upgrade the supported TeamCity version to latest in 2019.x, by migrating the docker images and test data.

When completed, this should bump a major on the library version from 0.x to 1.0

Support TeamCity project connections

Hi there,

It would be useful if this library supported managing TeamCity project connections.

Initially, we're looking for support for Hashicorp Vault and GitHub, however there are a number of other connection types that could be useful to others.

We'd be interested in contributing support for this functionality, however wanted to confirm if this is something that would be of use to the library, and also look at the best route for implementing.

Will get an initial PR up for review soon :)

Parameters should return Inherited property

When projects are inherited to Build Configurations, the SDK returns them normally without a way of knowing whether these parameters are inherited or not.

TriggerVcs rules and branch_filter are plain strings

TriggerVcs.Rules and TriggerVcs.BranchFilters properties should be typed as []string.

Enable repeatable, fast running tests with teamcity docker container

Currently when local development environment doesn't exist, it is required to perform manual steps before tests are able to run. This blocks #1 .

Support querying projects by name

Trigger model doesn't contain BuildTypeID property

Triggersdoesn't accept BuildTypeID in the constructor.
This makes it hard to reason, since it's only injected when the trigger is created by TriggerService.

• Make it required in the constructor
• Remove redundant Sets in TriggerServicewhen creating/retrieving.

[IMPORTANT] Looking for maintainers

Hello,

If you're an user for this project and would like to contribute, I don't have the bandwidth to maintain it solo anymore at this time. I've listed it at Adoptoss.org here: https://adoptoposs.org/p/d192c8d7-51d4-4d49-b801-70d0ee4d1d39

Please get in touch if you'd like to become a maintainer for this project.

Thanks!

Return Step collections with BuildType resource

Include the steps when deserializing the BuildType resource.

Refactor Steps to strongly typed model

Currently, the only supported step type "powershell" has a builder to abstract away the details of which properties much be set to talk to TC API.

This issue is to model steps as fully strongly typed entities, and get rid of the builder pattern. The implementation can follow the more refined approach of custom JSON serialization used for Build Features, such as the Github Status Publisher.

v1.2 is broken?

When I run go mod vendor:

code.cfops.it/ew/release-automation/internal/workflow imports
        github.com/cvbarros/go-teamcity: module github.com/cvbarros/go-teamcity@latest found (v1.2.0), but does not contain package github.com/cvbarros/go-teamcity

Implement Scheduled Triggers

In the same fashion as VCS Triggers, implement support for Scheduled Triggers for Build Configurations.

Handle error properly when adding more than one VCS Trigger

TeamCity returns an error if adding more than one VCS Trigger to a build configuration.
Currently, the UI hides the option to select a VCS Trigger in case an existing VCS Trigger has been added.

Possible workarounds

1. Do a GET first to verify, before the POST to create. Return a specific error in case another VCS Trigger exists.
2. POST regardless and handle TeamCity response gracefully and return error to caller.

Ordering of sub-projects and build configurations

REST API has undocumented endpoints for GET/PUT sub-projects and buildConfiguration display order, as implemented by https://youtrack.jetbrains.com/issue/TW-41796

403 Unauthorized when creating project fails silently

There is no error returned when creating a project faced with 403 Unauthorized response from TeamCity server.

build-type: remove unused `projectID` field in the create method

context: #80 (comment)

Migrate to go 1.11 and modules

Not possible to specify VCS Root for FeatureCommitPublisher

FeatureCommitStatusPublisheris missing the option to specify the VcsRootID, which by default applies to "All attached VCS Roots" to the build configuration.
This issue is to flexibilize so it is possible to specify which VCS Root the commit publisher should be attached to.

panic if I don't have correct rights

Hi there, I found the problem in case if I do Get for id, where I don't have (full) rights.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x11b12a8]

goroutine 1 [running]:
github.com/cvbarros/go-teamcity/teamcity.(*Parameters).NonInherited(0x0, 0xc000306aa0)
	/home/seidl/GoWorkspace/pkg/mod/github.com/cvbarros/[email protected]/teamcity/parameter.go:187 +0x78
github.com/cvbarros/go-teamcity/teamcity.(*ProjectService).GetByID(0xc0004fc040, 0xc00004a730, 0xd, 0x1, 0x1, 0xe)
	/home/seidl/GoWorkspace/pkg/mod/github.com/cvbarros/[email protected]/teamcity/project.go:123 +0x112
main.Teamcity(0xc000147ba0, 0x8b000000014053c0)

the API response looks like

{
    "id": "bbc",
    "name": "BBC",
    "parentProjectId": "_Root",
    "href": "/httpAuth/app/rest/projects/id:bbc",
    "webUrl": "https://teamcity/project.html?projectId=bbc",
    "parentProject": {
        "id": "_Root",
        "name": "<Root project>",
        "description": "Contains all other projects",
        "href": "/httpAuth/app/rest/projects/id:_Root",
        "webUrl": "https://teamcity/project.html?projectId=_Root"
    },
    "buildTypes": {
        "count": 2,
        "buildType": [
            {
                ...
            },
            {
                ...
            }
        ]
    },
    "projects": {
        "count": 0
    }
}

From my point of view, it is a bug. The one option is to get Project struct without that information, second is do error before call method on (in this case non-exists) Parameters https://github.com/cvbarros/go-teamcity/blob/master/teamcity/project.go#L123

Enable CI for the project

Requirements:

• Choose a free CI platform where is possible to spinup Teamcity as a docker container
• Must run ALL tests on PR inspection since even integration tests run fast enough
• Protect master branch

Add Build Configuration Options

Under "General Settings" for the build configuration UI, there are some options and advanced options yet not supported, such as:

• Build Counter
• Artifact Rules
• Build Options
  • Enable Hanging Builds Detection
  • Allow Triggering Personal Builds
  • Enable Status Widget
  • Limit the number of simultaneous builds

Strongly typed model for VCS Roots for reads

When reading reading a VCS root of type Git, most of the core settings are stored as Properties. This is fine for creation since the constructor NewGitVcsRootOptions and variants can create instances properly configured using GitVcsRootOptions.

However, if the SDK user wants to read back a VcsRoot, it has to rely upon inspecting Properties collection to figure out the settings. This issue is to implement a hierarchy of VcsRoot, enabling strongly typed properties to be deserialized.

There are two options:

1. Convert VcsRoot to an interface, and create an implementation type GitVcsRoot. Then VcsRootService can return the interface. This approach has been tried in the BuildFeature, but required a lot of boilerplate for getters/setters and custom JSON serialization. I prefer this approach, despite the boilerplate.

//Clients then have to cast and know the type of 
//VcsRoot if they want to interact in strongly typed manner.
gitVcs := teamcity.GetByID(vcsID).(*GitVcsRoot) 

//Or if they want to just list, inspect basic properties
vcsRoot := teamcity.GetByID(vcsID)

2. Create strongly typed methods for each VCS type in VcsRootService. This option will explode the number of Get/Create methods but can provide better type safety. I dislike this approach as it will pollute the API and will definitely violate the Open-Closed Principle, and will require public API changes for each type of VCS Root added (more methods to VcsRootService).

gitVcs := teamcity.GetGitVcsByID(vcsID)

tfsRoot := teamcity.GetTfsVcsByID(vcsID)

Support SnapshotDependency full options

Currently, SnapshotDependency is created with default UI options. This issue is to add support for fully configuring all UI options when adding a snapshot dependency to a build configuration.

versioned-settings: support for context parameters

Versioned Settings support Context Parameters, which allow Kotlin Versioned Settings Files to retrieve values passed in via: DslContext.getParameter(name, defaultValue)

This is exposed in the XML as keys prefixed with context.hello - so will be a map context in the JSON

<projectFeature id="PROJECT_EXT_28" type="versionedSettings" href="/app/rest/projects/id:Example/projectFeatures/id:PROJECT_EXT_28">
  <properties count="8" href="/app/rest/projects/id:Example/projectFeatures/id:PROJECT_EXT_28/properties">
    <property name="buildSettings" value="PREFER_VCS"/>
    <property name="context.hello" value="world"/>
    <property name="credentialsStorageType" value="credentialsJSON"/>
    <property name="enabled" value="true"/>
    <property name="format" value="kotlin"/>
    <property name="rootId" value="ExampleVcs"/>
    <property name="showChanges" value="false"/>
    <property name="useRelativeIds" value="true"/>
  </properties>
</projectFeature>

Migrate to CircleCI

Migrate status checks and master builds to CircleCI.

Enable Update for Project Resource

Allow updating of Project resource the same way as BuildConfiguration. Refactor Parameteters to be part of the entity itself, instead of relying upon a separate service.

• Update for Project (Description field)
• Update allows changing parameters on a single API call

Add "CommandLine" step type

Make it possible to create build steps of type "CommandLine".

Support customization of parameter types

When creating parameters, TeamCity allows to edit a full specification, including the possibility of creating "sensitive" parameters.

This issue is to give support for:

• Password type
• Display Type (hidden, prompt, normal)
• Parameter Description
• Checkboxes
• Select Lists and it's items
• Read-Only

Add support for extended Git VCS Root options

In addition to general settings, VCS Root attach screen has "Advanced Options" that modify the build configuration settings.

listing sub projects

Looking at the Project struct I can't see a way of listing sub project to a project. Is there another way this can be done that I am missing? I see there is a ParentProject but no child/sub project.

Enhance the API to support build configuration conditions

Enhance the build configuration step API to support mode and conditions, required in the Teamcity Terraform Provider.

See the related issue here.

ArtifactDependency has no strongly-typed deserialization

ArtifactDependency when being retrieved by the SDK, doesn't deserialize the ArtifactDependencyOptions model, just exposes the raw TC API model object.

This issue is to encapsulate the Properties collection for ArtifactDependency resource.

Implement Finish Build Triggers

In the same fashion as VCS Triggers, implement support for "Finish Build" Triggers for Build Configurations.

Support for Artifact Dependencies in BuildType

Currently, it is only possible to add SnapshotDependency to a build configuration. This issue is to implement support for also manage ArtifactDependency for build configurations.

Allow Build Configuration Templates

Allow creation of build configuration templates:

• Make it possible to create/read/update/delete a template
• Allow attaching/detaching to an existing build configuration