-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TT-561] move chainlink-env as a package (commit-splitted) #747
Conversation
f39d61e
to
b31a011
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #747 +/- ##
==========================================
+ Coverage 21.43% 21.75% +0.32%
==========================================
Files 31 32 +1
Lines 4167 4183 +16
==========================================
+ Hits 893 910 +17
+ Misses 3182 3181 -1
Partials 92 92
☔ View full report in Codecov by Sentry. |
It might make sense to put the chainlink-env package into a folder called k8s instead of env. My reasoning for this is that we have a folder called docker which hosts the docker specific stuff so it makes sense if you want to look for k8s specific stuff you would open the k8s folder instead of env. |
b31a011
to
65125d5
Compare
65125d5
to
4612bed
Compare
4612bed
to
55049e8
Compare
55049e8
to
260ff81
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The part I am unsure about is whether we should add this as a package or just migrate the code in so we only have the 1 go project. They both have their pros and cons. 1 go project is easier to work within but the separation of the two may make it easier for projects that only want to import 1 part or the other. I think most projects will use both anyways so it may make sense to have it just be 1 project instead of two. @AnieeG @skudasov @kalverra @gheorghestrimtu @lukaszcl Thoughts?
@tateexon also thought about that and checked how many projects use only In the end I decided against having
Anyway let me know your thoughts guys. Also, I was thinking that if we stick to packages |
Removing my review for now in case we switch to 1 go project
|
||
```go | ||
// We use the chainlink-env library to make and handle deployed resources | ||
import "github.com/smartcontractkit/chainlink-env/environment" | ||
// We use the env package to make and handle deployed resources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The package name in comment
SonarQube Quality Gate 0 Bugs No Coverage information |
Changes:
chainlink-env
code needs migrated and converted to a package ✅**
imports
andexamples
excluded from analysiachainlink
tests work using migrated code: PR