feat: Support CandlePart for WMA

facioquo / stock-indicators-python

Stock Indicators for Python. Maintained by @LeeDongGeon1996

https://python.StockIndicators.dev

Apache License 2.0

221 stars 37 forks source link

feat: Support CandlePart for WMA #225

Closed LeeDongGeon1996 closed 2 years ago

LeeDongGeon1996 commented 2 years ago

Description

Support CandlePart for WMA.

Checklist

[x] My code follows the existing style, code structure, and naming taxonomy
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have performed a self-review of my own code and included any verifying manual calculations
[x] I have added or updated unit tests that prove my fix is effective or that my feature works, and achieves sufficient code coverage. New and existing unit tests pass locally and in the build (below) with my changes
[x] My changes generate no new warnings and running code analysis does not produce any issues
[x] I have added or run the performance tests that depict optimal execution times
[x] I have made corresponding changes to the documentation

LeeDongGeon1996 commented 2 years ago

It looks like it fetches unreleased version of dll when replacing dll to the latest.

DaveSkender commented 2 years ago

This DLL auto-fetcher should only take the latest package from main builds with the released tag. It looks like it's not considering the released tag and taking the latest main build package instead.

LeeDongGeon1996 commented 2 years ago

This DLL auto-fetcher should only take the latest package from main builds with the released tag. It looks like it's not considering the released tag and taking the latest main build package instead.

You mean it is temporary issue on Azure?

DaveSkender commented 2 years ago

You mean it is temporary issue on Azure?

I'm not sure. As written, the build looks okay. It may be a bug with that specific Task in the Pipeline.

      - task: DownloadPipelineArtifact@2
        displayName: "Fetch DLL"
        inputs:
          source: specific
          project: xxxxxxxxxxxxx
          pipeline: 21
          runVersion: latestFromBranch
          runBranch: refs/heads/main
          tags: released
          artifact: packages
          patterns: "*.nupkg"

ref: https://github.com/microsoft/azure-pipelines-tasks/issues/13101

LeeDongGeon1996 commented 2 years ago

Umm.. I think that it's a bad idea to use unreleased dll from manual build to avoid this issue. Could you force-merge it, if possible?

DaveSkender commented 2 years ago

Umm.. I think that it's a bad idea to use unreleased dll from manual build to avoid this issue. Could you force-merge it, if possible?

Yes, I agree, it's bad. It's not supposed to do that and I'm not sure why it is doing it suddenly. I think it was working properly before. I can't troubleshoot at the moment, but may be able to look at it later.

It's probably okay to override the merge, as long as the code is good and we don't release this version before we get a good build. Is that what you want to do here?

LeeDongGeon1996 commented 2 years ago

It's probably okay to override the merge, as long as the code is good and we don't release this version before we get a good build. Is that what you want to do here?

Yeah, that's right. I think we can ignore CI test for now and just merge. This failure is false negative.