azure/azure-pipeline-go

Package pipeline implements an HTTP request/response middleware pipeline whose policy objects mutate an HTTP request's URL, query parameters, and/or headers before the request is sent over the wire. This is the Go implementation.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

azure-pipeline-go's Issues

Possible issue observed in upstream dependency go-ieproxy

We've received reports from our users of possible hangs/crashes in go-ieproxy when running on Windows 10. From downstream issue (dapr/cli#707):

C:\Users\mcain>%userprofile%.dapr\bin\daprd.exe -version
Exception 0xc0000005 0x0 0x7ff9c85b0fff 0x1dcc4280000
PC=0x1dcc4280000

syscall.Syscall(0x7ff9c7eaadc0, 0x3, 0xc0005979c8, 0x0, 0x800, 0x0, 0x0, 0x0)
C:/hostedtoolcache/windows/go/1.16.3/x64/src/runtime/syscall_windows.go:330 +0xe9
golang.org/x/sys/windows._LoadLibraryEx(0xc0005979c8, 0x0, 0x800, 0xc, 0xc, 0x0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/zsyscall_windows.go:2273 +0x96
golang.org/x/sys/windows.LoadLibraryEx(0x3d1bcfb, 0xb, 0x0, 0x800, 0xc000422b00, 0x30000, 0x5be42c0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/zsyscall_windows.go:2269 +0x9f
golang.org/x/sys/windows.loadLibraryEx(0x3d1bcfb, 0xb, 0x2030001, 0x2030000, 0x20, 0x422269e)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/dll_windows.go:407 +0x66
golang.org/x/sys/windows.(*LazyDLL).Load(0xc000511500, 0x0, 0x0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/dll_windows.go:242 +0xca
golang.org/x/sys/windows.(*LazyProc).Find(0xc000511560, 0x0, 0x0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/dll_windows.go:305 +0xc5
golang.org/x/sys/windows.(*LazyProc).mustFind(...)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/dll_windows.go:323
golang.org/x/sys/windows.(*LazyProc).Call(0xc000511560, 0xc000502150, 0x5, 0x5, 0x4223768, 0x2030001, 0x20, 0x42285d2)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/[email protected]/windows/dll_windows.go:347 +0x36
github.com/mattn/go-ieproxy.getUserConfigFromWindowsSyscall(0x0, 0x0, 0x0)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/[email protected]/ieproxy_windows.go:79 +0xa6
github.com/mattn/go-ieproxy.writeConf()
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/[email protected]/ieproxy_windows.go:33 +0x66
sync.(*Once).doSlow(0x5c365f8, 0x3e473b0)
C:/hostedtoolcache/windows/go/1.16.3/x64/src/sync/once.go:68 +0xf7
sync.(*Once).Do(...)
C:/hostedtoolcache/windows/go/1.16.3/x64/src/sync/once.go:59
github.com/mattn/go-ieproxy.getConf(...)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/[email protected]/ieproxy_windows.go:23
github.com/mattn/go-ieproxy.GetConf(...)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/[email protected]/ieproxy.go:36
github.com/mattn/go-ieproxy.proxyMiddleman(0xc0008003e0)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/[email protected]/proxyMiddleman_windows.go:12 +0x486
github.com/mattn/go-ieproxy.GetProxyFunc(...)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/[email protected]/GetProxyFunc.go:10
github.com/Azure/azure-pipeline-go/pipeline.newDefaultHTTPClient(0xa4e8a9)
C:/Users/runneradmin/go/pkg/mod/github.com/!azure/[email protected]/pipeline/core.go:208 +0x2d
github.com/Azure/azure-pipeline-go/pipeline.init()
C:/Users/runneradmin/go/pkg/mod/github.com/!azure/[email protected]/pipeline/core.go:202 +0x29

We have not been able to reproduce this issue ourselves, but it seems to resemble a known issue in upstream repo: mattn/go-ieproxy#17

Versioning

What's going on with the versioning for the releases in this repo - it went from 0.1.0 -> 1.1.3, back down to 0.1.3 -> 0.1.4. Surely all releases should have a major rev of 1 at this point...? It seems like this just causes lots of weird issues since some tools can't tell whether or not it should actually update based off the rev number, and you instead have to just fetch the latest @ master.

can not compile with freebsd

the code can not compile with freebsd after #17

Is this project to be considered EOL / dead?

I'am looking for az pipelines go REST bindings and found this project. Is this project no longer developed / maintained or EOL? (since there has been no actions since quiet some time now)

Panic on darwin due to go-ieproxy

github.com/mattn/go-ieproxy performs syscalls which can panic due to unexpected signal on MacOS: mattn/go-ieproxy#35

This issue is fixed in github.com/mattn/[email protected]. However, given #29 and #31, it's probably better to remove this dependency rather than upgrade it.

 fatal error: unexpected signal during runtime execution
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7ff8054f94f6]
 
 runtime stack:
 runtime.throw({0x4fa5528, 0xffffffffffffffff})
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/panic.go:1198 +0x71
 runtime.sigpanic()
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/signal_unix.go:719 +0x396
 
 goroutine 1 [syscall, locked to thread]:
 runtime.cgocall(0x4c4b840, 0xc0001a17e0)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/cgocall.go:156 +0x5c fp=0xc0001a17b8 sp=0xc0001a1780 pc=0x400613c
 github.com/mattn/go-ieproxy._Cfunc_CFNumberGetValue(0x0, 0x9, 0xc0000425b8)
       _cgo_gotypes.go:191 +0x49 fp=0xc0001a17e0 sp=0xc0001a17b8 pc=0x431f0e9
 github.com/mattn/go-ieproxy.cfNumberGetGoInt.func1(0x431f4a9, 0x4c4b8e0)
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/ieproxy_darwin.go:43 +0x59 fp=0xc0001a1820 sp=0xc0001a17e0 pc=0x431fb19
 github.com/mattn/go-ieproxy.cfNumberGetGoInt(0x0)
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/ieproxy_darwin.go:43 +0x37 fp=0xc0001a1850 sp=0xc0001a1820 pc=0x431fa97
 github.com/mattn/go-ieproxy.writeConf()
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/ieproxy_darwin.go:76 +0x275 fp=0xc0001a1940 sp=0xc0001a1850 pc=0x431ff95
 sync.(*Once).doSlow(0x7, 0xe)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/sync/once.go:68 +0xd2 fp=0xc0001a19a8 sp=0xc0001a1940 pc=0x40848f2
 sync.(*Once).Do(...)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/sync/once.go:59
 github.com/mattn/go-ieproxy.getConf(...)
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/ieproxy_darwin.go:23
 github.com/mattn/go-ieproxy.GetConf(...)
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/ieproxy.go:36
 github.com/mattn/go-ieproxy.proxyMiddleman()
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/proxy_middleman_darwin.go:12 +0x57 fp=0xc0001a1a48 sp=0xc0001a19a8 pc=0x431e957
 github.com/mattn/go-ieproxy.GetProxyFunc(...)
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/mattn/[email protected]/proxy_middleman.go:10
 github.com/Azure/azure-pipeline-go/pipeline.newDefaultHTTPClient()
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/!azure/[email protected]/pipeline/core.go:208 +0x1d fp=0xc0001a1a80 sp=0xc0001a1a48 pc=0x4322e7d
 github.com/Azure/azure-pipeline-go/pipeline.init()
       /Users/dcouture/.asdf/installs/golang/1.17.9/packages/pkg/mod/github.com/!azure/[email protected]/pipeline/core.go:202 +0x19 fp=0xc0001a1aa0 sp=0xc0001a1a80 pc=0x4324f59
 runtime.doInit(0x5c8fdc0)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/proc.go:6498 +0x123 fp=0xc0001a1bd8 sp=0xc0001a1aa0 pc=0x40490c3
 runtime.doInit(0x5c94b20)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001a1d10 sp=0xc0001a1bd8 pc=0x4049011
 runtime.doInit(0x5c8dc00)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001a1e48 sp=0xc0001a1d10 pc=0x4049011
 runtime.doInit(0x5c93800)
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/proc.go:6475 +0x71 fp=0xc0001a1f80 sp=0xc0001a1e48 pc=0x4049011
 runtime.main()
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/proc.go:238 +0x1e6 fp=0xc0001a1fe0 sp=0xc0001a1f80 pc=0x403be06
 runtime.goexit()
       /Users/dcouture/.asdf/installs/golang/1.17.9/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc0001a1fe8 sp=0xc0001a1fe0 pc=0x406dce1

ErrorNode should not always implement Causer interface

I am using the package github.com/Azure/azure-storage-blob-go/2016-05-31/azblob to add support for Azure Storage to the Pulumi project (pulumi/pulumi#2026). Currently, when I receive a StorageError the Pulumi codebase uses errors.Wrap(err, "") to add annotations to the original error. The error is then unwrapped using errors.Cause(err) to determine if the original error was a "not found" error (BlobNotFound in our case). However, as the current implementation of ErrorNode can always be type asserted against the Causer interface, even if the cause error is nil, it breaks the expected behavior for errors.Cause(err) defined here. I've inlined the code so that I can annotate.

func Cause(err error) error {
	type causer interface {
		Cause() error
	}

	for err != nil {
		cause, ok := err.(causer) //  1. This will return OK, even if the cause is nil
		if !ok {
			break // 4. We actually want to break here with the original error
		}
		err = cause.Cause() // 2. This will then return nil
	}
	return err // 3. Meaning this will return nil
}

This means we get nil back rather than the nested StorageError as expected and in accordance to how the standard library errors work.

I have created a temporary work around in pulumi by defining a new error struct that implements the StorageError interface but does not implement Causer and this has fixed my code. This is available here: https://github.com/pulumi/pulumi/blob/03d8939eee39599dcee8e3328fcf6c1da6ce1f47/pkg/backend/filestate/storage/azure/error.go

My proposal would be to define a new error type pcErrorNoCause and a new type ErrorNodeNoCause that doesn't implement the Causer interface. Then in NewError() error check whether the cause parameter is nil and if so return a pcErrorNoCause error instead of the existing pcError. Something similar to below:

// NewError creates a simple string error (like Error.New). But, this
// error also captures the caller's Program Counter and the preceding error.
func NewError(cause error, msg string) error {
        if cause != nil {
                return &pcError{
		    ErrorNode: ErrorNode{}.Initialize(cause, 3),
		    msg:       msg,
	        }
        }
	return &pcErrorNoCause{
		ErrorNode: ErrorNodeNoCause{}.Initialize(3),
		msg:       msg,
	}
}

Offending code:

azure-pipeline-go/pipeline/error.go

Line 106 in b8e3409

func NewError(cause error, msg string) error {

Does this sound reasonable? If so, I am happy to PR the change.

Upstream dependency go-ieproxy requires CGO

I have a project that depends on azure-pipeline-go, and a user has reported that it no longer compiles unless CGO compilation is enabled. This is new in the 0.0.2 and 0.0.3 version of go-ieproxy.

google/go-cloud#3114 is the bug report. Basically, compilation fails unless CGO_ENABLED=1 (Go defaults it to 1 in some scenarios, but you can always disable it).

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

change of name broke downstream

I think 6ef5c39 might've broken Azure/azure-storage-blob-go.

output of go get -u github.com/Azure/azure-storage-blob-go/2016-05-31/azblob:

# github.com/Azure/azure-storage-blob-go/2016-05-31/azblob
../../Azure/azure-storage-blob-go/2016-05-31/azblob/credential_anonymous.go:27:78: undefined: pipeline.Configuration
../../Azure/azure-storage-blob-go/2016-05-31/azblob/credential_shared_key.go:42:65: undefined: pipeline.Configuration
../../Azure/azure-storage-blob-go/2016-05-31/azblob/credential_shared_key.go:53:11: undefined: pipeline.Configuration

I discovered this while running tests in the samples repo :)

Bump github.com/mattn/go-ieproxy to v0.0.1 in go.mod file

The version of github.com/mattn/go-ieproxy pinned in go.mod isn't Go modules aware which creates unnecessary complications for projects depending (directly or indirectly) on github.com/Azure/azure-pipeline-go. Switching to v0.0.1 would solve the issue.

I also recommend to run go mod tidy after bumping the version.

the mac signature found in the http request is not the same as the computed signature

the mac signature found in the http request is not the same as the computed signature