Git Product home page Git Product logo

go-arty's Introduction

go-arty

GoDoc Go Report Card codecov

go-arty is a Go client library for accessing the Artifactory and Xray API.

Artifactory

Usage

With Go Modules

import "github.com/target/go-arty/v2/artifactory"

Without Go Modules

import "github.com/target/go-arty/artifactory"

Construct a new Artifactory client, then use the various services on the client to access different parts of the Artifactory API. For example:

client, _ := artifactory.NewClient("artifactory.company.com", nil)

// list all users from the artifactory server
users, _, err := client.Users.GetAllSecurity()

Authentication

The artifactory package allows you to pass basic auth or an API Key.

Example using basic auth:

client, _ := artifactory.NewClient("artifactory.company.com", nil)

client.Authentication.SetBasicAuth("username", "password")

Example using API Key:

client, _ := artifactory.NewClient("artifactory.company.com", nil)

client.Authentication.SetTokenAuth("token")

Xray

Usage

With Go Modules

import "github.com/target/go-arty/v2/xray"

Without Go Modules

import "github.com/target/go-arty/xray"

Construct a new Xray client, then use the various services on the client to access different parts of the Xray API. For example:

client, _ := xray.NewClient("artifactory.company.com", nil)

// list all users from the xray server
users, _, err := client.Users.GetAll()

Authentication

The xray package allows you to pass basic auth or a token.

NOTE: To get the token for Xray, you have to hit an API endpoint that returns the token. See the docs for more info.

Example using basic auth:

client, _ := xray.NewClient("xray.company.com", nil)

client.Authentication.SetBasicAuth("username", "password")

Example using token:

client, _ := xray.NewClient("xray.company.com", nil)

client.Authentication.SetTokenAuth("token")

Creating/Updating Resources

All structs in this library use pointer values for all non-repeated fields. This allows distinguishing between unset fields and those set to a zero-value. Helper functions have been provided to easily create these pointers for string, bool, and int values. For example:

// create a new user named "admin"
user := &artifactory.SecurityUser{
	Name:     artifactory.String("admin"),
	Email:    artifactory.String("[email protected]"),
	Password: artifactory.String("secretPassword"),
	Admin:    artifactory.Bool(true),
}

client.Users.CreateSecurity(user)

Users who have worked with protocol buffers should find this pattern familiar.

Versioning

In general, go-arty follows semantic versioning as closely as we can for tagging releases of the package. For self-contained libraries, the application of semantic versioning is relatively straightforward and generally understood. But because go-arty is a client library for the Artifactory API and the Xray API, which both change behavior frequently, we've adopted the following versioning policy:

  • We increment the major version with any incompatible change to either package (artifactory or xray) in this library, including changes to the exported Go API surface or behavior of the API.
  • We increment the minor version with any backwards-compatible changes to functionality.
  • We increment the patch version with any backwards-compatible bug fixes.

Road map

This library was initially developed for internal applications at Target, so API methods will likely be added in the order that they are required.

Contributing

We always welcome new PRs! See Contributing for further instructions.

Bugs and Feature Requests

Found something that doesn't seem right or have a feature request? Please open a new issue.

Copyright and License

license

Copyright (c) 2018 Target Brands, Inc.

go-arty's People

Contributors

collisonchris avatar delta592 avatar dependabot[bot] avatar jbrockopp avatar joeh90 avatar jordansussman avatar kneal avatar renovate[bot] avatar timothytitan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

go-arty's Issues

Add missing NuGet fields to RemoteRepository struct

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • Add missing NuGet fields to RemoteRepository struct

Your environment

  • Artifactory 6.15.0

Expected behavior

  • Should be able to set NuGet remote repository fields
  • feedContextPath *string
  • downloadContextPath *string
  • v3FeedUrl *string

Actual behavior

  • Unable to currently set NuGet remote repository fields: feedContextPath, downloadContextPath, v3FeedUrl

Steps to Reproduce

N/A

Rename BypassHeadRequest to BypassHeadRequests on RemoteRepository struct

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • BypassHeadRequests field is incorrectly named BypassHeadRequest in RemoteRepository struct

Your environment

  • Artifactory 6.15.0

Expected behavior

  • Should be able to set BypassHeadRequests field

Actual behavior

  • Unable to set BypassHeadRequests field as it is incorrectly named BypassHeadRequest in RemoteRepository struct

Steps to Reproduce

N/A

Cannot get latest version: module contains a go.mod file, so module path should be github.com/target/go-arty/v2

Background

The github.com/target/go-arty uses Go modules and the current release stream version is v2. It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation and enforced since the most recent versions of Go. The module path should be “github.com/target/go-arty/v2”. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Using go get (under go1.13 and go1.14) does not work for github.com/target/[email protected] .
I consider this a pretty high severity issue since not doing so prevents any other Go project also using Go Modules to properly require target/go-arty on version v2.1.2 as a dependency, resulting in errors like:

invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

SO anyone using Go modules will not be able to easily use any newer version of target/go-arty

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v2.1.0 of the target/go-arty:

$ go get github.com/target/[email protected]
go get github.com/target/[email protected]: github.com/target/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

Solution

1. Kill the go.mod files.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules). Importing specific versions would work, but they'd receive the +incompatible prefix and would need to be manually upgraded.

Probably best option short-term -- better to not use Go modules than use it incorrectly.
Also, best option for older branches/versions that aren't maintained.

2. Make breaking changes

Patch the go.mod file to declare the module as github.com/target/go-arty/v2 as per the specs. AND adjust all internal imports.

There are two alternative mechanisms to release a v2 or higher module. Note that with both techniques, the new module release becomes available to consumers when the module author pushes the new tags. Using the example of creating a v3.0.0 release, the two options are:

Major branch: Update the go.mod file to include a /v3 at the end of the module path in the module directive (e.g., module github.com/my/module/v3). Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0.

  • Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the "Semantic Import Versioning" section above).
  • A community tool github.com/marwan-at-work/mod helps automate this procedure. See the repository or the community tooling FAQ below for an overview.
  • To avoid confusion with this approach, consider putting the v3.. commits for the module on a separate v3 branch.
  • Note: creating a new branch is not required. If instead you have been previously releasing on master and would prefer to tag v3.0.0 on master, that is a viable option. (However, be aware that introducing an incompatible API change in master can cause issues for non-modules users who issue a go get -u given the go tool is not aware of semver prior to Go 1.11 or when module mode is not enabled in Go 1.11+).
  • Pre-existing dependency management solutions such as dep currently can have problems consuming a v2+ module created in this way. See for example dep#1962.

Major subdirectory: Create a new v3 subdirectory (e.g., my/module/v3) and place a new go.mod file in that subdirectory. The module path must end with /v3. Copy or move the code into the v3 subdirectory. Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0.

  • This provides greater backwards-compatibility. In particular, Go versions older than 1.9.7 and 1.10.3 are also able to properly consume and build a v2+ module created using this approach.
  • A more sophisticated approach here could exploit type aliases (introduced in Go 1.9) and forwarding shims between major versions residing in different subdirectories. This can provide additional compatibility and allow one major version to be implemented in terms of another major version but would entail more work for a module author. An in-progress tool to automate this is goforward. Please see here for more details and rationale, along with a functioning initial version of goforward.
  • Pre-existing dependency management solutions such as dep should be able to consume a v2+ module created in this way.

3. Major version bump / repository change

Leave v2 as a dead version and bump to v3 with the path changes.

4. Remain unchanged

Don’t want to fix it. Not intended to be used as a library and does not make any guarantees about the API.

5. Let the user change

The standard rule of go modules conflicts with your development mode. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/target/go-arty@version-tag, the install procedure would be something like:
(1)Search for the tag you want (in browser)
(2)Get the commit hash for the tag you want
(3)Run go get github.com/target/go-arty@commit-hash
(4)Edit the go.mod file to put a comment about which version you actually used

References

Add support for configuring replications

Add missing fields to RemoteRepository struct

Subject of the issue

  • Add missing fields to RemoteRepository struct: enableTokenAuthentication, listRemoteFolderItems

Your environment

  • Artifactory version: 6.17.0
  • Golang version: 1.13
  • Operating System: Windows
  • Database type/version (if relevant): N/A

Open Source

Integrations

  • Enable travis ci
  • Verify GoDoc results
  • Verify goreportcard results

Communication

  • Update go-artifactory issue

Create function for /artifactory/api/users

Below are required fields for qualifying your issue to our support team

Subject of the issue

The Artifactory API has a number of undocumented endpoints underneath /api/users/*, and those endpoints provide further information beyond what the GetAll does.

Importance of the issue

While the /api/security/users endpoint is typically fine, we do have some use cases that require information from the /api/users endpoint.

Your environment

  • Artifactory version - 6.3.2

Support smart remote repository fields on remote repository struct

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • Add support for smart remote repository fields on remote repository struct

Your environment

  • Artifactory 6.15.0

Expected behavior

  • Unmarshal contentSynchronisation json to nested struct: "contentSynchronisation": { "enabled": false (default), "statistics": { "enabled": false (default) }, "properties": { "enabled": false (default) }, "source": { "originAbsenceDetection": false (default) } },

Actual behavior

N/A

Steps to Reproduce

N/A

artifacts test fails on Windows OS due to different error message

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • Go tests fail on Windows OS

Your environment

  • Go 1.13
  • Windows OS

Expected behavior

  • All Go tests should pass

Actual behavior

  • artifacts test fails on bad file test due to different error message produced by Windows OS: "open this/is/a/bad/path.txt: The system cannot find the path specified."

Steps to Reproduce

  1. Run go test github.com/target/go-arty/... in a Windows environment

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

Detected dependencies

github-actions
.github/workflows/test.yml
  • actions/checkout v4
  • actions/setup-go v5
  • codecov/codecov-action v4
.github/workflows/validate.yml
  • actions/checkout v4
  • actions/setup-go v5
gomod
go.mod
  • go 1.22
  • github.com/coreos/go-semver v0.3.1
  • github.com/franela/goblin v0.0.0-20211003143422-0a4f594942bf@0a4f594942bf
  • github.com/gin-gonic/gin v1.10.0
  • github.com/google/go-querystring v1.1.0
  • github.com/tidwall/gjson v1.17.1
  • gopkg.in/yaml.v2 v2.4.0

  • Check this box to trigger a request for Renovate to run again on this repository

Get/Set/Delete properties on repositories

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • Add the ability to get, set and delete properties on repositories

Your environment

  • Artifactory 6.15.0

Expected behavior

  • Gets, sets and deletes properties directly on repository (i.e. empty path)
  • Either modify existing GetItemProperties, SetItemProperties, DeleteItemProperties functions to handle empty paths or create new functions GetRepoProperties, SetRepoProperties, DeleteRepoProperties (to pretty much duplicate the former)
  • Happy to contribute either of these myself & add tests

Actual behavior

  • N/A

Steps to Reproduce

N/A

storage.go: A File has a Size of type string and a FileListItem has a Size of type int

Below are required fields for qualifying your issue to our support team

Subject of the issue

storage.go: A File has a Size of type string and a FileListItem has a Size of type int

  • Briefly describe your issue. More details can be added below.

Your environment

  • Artifactory version and/or Xray version
    Artifactory version 2.0.0

  • Golang version
    go version go1.10.3 darwin/amd64

  • Operating System
    Mac OS X: Mojave

  • Database type/version (if relevant)
    N/A

Expected behavior

Consistent structure types

  • Tell us what should happen
    Both a File and FileListItem should represent size as an int.

Actual behavior

Ints and strings have to be handled differently/converted

  • Tell us what happens instead, including any relevant errors or stack trace
    N/A
  • Verify you have redacted any sensitive hostnames, credentials, application names, etc from these errors/stack traces
    N/A

Steps to Reproduce

  1. See Line 72 of storage.go
  2. See Line 170 of storage.go

Timestamps have unkeyed field - causes composite literal uses unkeyed fields warning

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • Briefly describe your issue. More details can be added below.

Your environment

  • Artifactory version and/or Xray version
    Artifactory version 2.0.0

  • Golang version
    go version go1.10.3 darwin/amd64

  • Operating System
    Mac OS X: Mojave

  • Database type/version (if relevant)
    N/A

Expected behavior

  • Tell us what should happen
    No warnings in client code. (in this case, it is in my test code)

Actual behavior

  • Tell us what happens instead, including any relevant errors or stack trace
    Compiler warnings

  • Verify you have redacted any sensitive hostnames, credentials, application names, etc from these errors/stack traces
    "severity": 4,
    "message": "github.com/target/go-arty/artifactory.Timestamp composite literal uses unkeyed fields",
    "source": "go-vet",
    "startLineNumber": 49,
    "startColumn": 1,
    "endLineNumber": 49,
    "endColumn": 2

Steps to Reproduce

  1. See line 43 of timestamp.go
    or this client code will cause the warning as well.
    t := artifactory.Timestamp{time.Now()}

Look into adding support for xray v2 api

As of Xray 2.4.x JFrog has started migrating endpoints from /v1/ to /v2. The specific notes from confluence are:

From version 2.4, JFrog Xray is introducing a new REST API version. The different endpoints specified in this page will be upgraded gradually over progressive version upgrades, while maintaining backward compatibility to previous API versions. Where new endpoints are available, the API Version will be listed. In these cases, you should make sure to use corresponding Base URL as specified below. If the API version is not specified, it means the endpoint is part of the V1 REST API and you should use the V1 base URL.

AccessToken management support

Below are required fields for qualifying your issue to our support team

Subject of the issue

  • There appears no support for creating and managing with Artifactory AccessTokens implemented

Your environment

  • Artifactory version 6.9.1 Pro

Expected behavior

Actual behavior

  • no support to create, delete a Token of a user

Steps to Reproduce

NA

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.