Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Remove vendor dir in /test #1417

Merged
merged 1 commit into from
Jun 3, 2022
Merged

Remove vendor dir in /test #1417

merged 1 commit into from
Jun 3, 2022

Conversation

dcantah
Copy link
Contributor

@dcantah dcantah commented Jun 3, 2022

Given this slows down development both for us and external contributors as for most changes one would need to run go mod vendor in /test to bring in the latest local hcsshim changes, I think it's time we removed this.

Pros:

  1. Easier for automated tooling like dependabot, and more recently a Microsoft security bot, to make PRs that can just be checked in. All of these automated PRs tend to fail as the bot doesn't know it would need to run go mod vendor in /test as well for our repo. The approach today to check these in is typically someone manually checks out the branch dependabot (or whatever other bot) made, vendor to test, and then push a new commit to those automated PRs and then we can check them in.

  2. Speeds up development flow as we don't need to go mod vendor in test before pushing almost every change.

  3. Speeds up external contributions as well as there's no extra step to follow to make a change to most things in /internal anymore. We state that this needs to be done in our README, but it's probably a testament to how odd our setup is that it's missed here and there.

Cons:

  1. We lose the main selling point of vendoring for our test dependencies which is that if one of our dependencies is no longer accessible (deleted, renamed, whatever else) we don't have a local copy included in our repo. This will increase our dependence on the Go modules proxy server which seems like a fair tradeoff, and I think we're fine with this for test dependencies at least.

I've removed the references to this extra step in the README as well as got rid of the CI step verifying that the vendor dir was up to date.

@dcantah dcantah requested a review from a team as a code owner June 3, 2022 09:08
@dcantah dcantah marked this pull request as draft June 3, 2022 09:58
@dcantah dcantah force-pushed the rm-testvendor branch 2 times, most recently from 9eb33d8 to 6a908ff Compare June 3, 2022 10:00
@dcantah dcantah marked this pull request as ready for review June 3, 2022 10:31
@dcantah
Copy link
Contributor Author

dcantah commented Jun 3, 2022

Need to rebase

katiewasnothere
katiewasnothere approved these changes Jun 3, 2022
View reviewed changes
Copy link
Contributor

@katiewasnothere katiewasnothere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm after rebase

@dcantah
Copy link
Contributor Author

dcantah commented Jun 3, 2022

My gosh, needs ANOTHER rebase

@dcantah
Remove vendor dir in /test
6201755 
Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
@dcantah dcantah merged commit 4e60239 into microsoft:master Jun 3, 2022
@dcantah dcantah mentioned this pull request Jun 7, 2022
Merged
kiashok pushed a commit to kiashok/hcsshim that referenced this pull request Jul 11, 2022
@dcantah
Remove vendor dir in /test (microsoft#1417)
3c37022 
Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
helsaawy added a commit to helsaawy/hcsshim that referenced this pull request Sep 8, 2023
@helsaawy
Remove vendor dir in /test (microsoft#1417)
91ac36d 
Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
(cherry picked from commit 4e60239)
Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
helsaawy added a commit that referenced this pull request Sep 8, 2023
@helsaawy
Remove vendor dir in /test (#1417) (#1894)
1eed5ba 
Given this slows down development both for us and external contributors
as for most changes one would need to run `go mod vendor` in /test to
bring in the latest local hcsshim changes, I think it's time we removed
this.

Pros:
1. Easier for automated tooling like dependabot, and more recently a
Microsoft security bot, to make PRs that can just be checked in.
All of these automated PRs tend to fail as the bot doesn't know it would
need to run go mod vendor in /test as well for our repo. The approach today
to check these in is typically someone manually checks out the branch
dependabot (or whatever other bot) made, vendor to test, and then push a
new commit to those automated PRs and then we can check them in.

2. Speeds up development flow as we don't need to go mod vendor in test
before pushing almost every change.

3. Speeds up external contributions as well as there's no extra step to
follow to make a change to most things in /internal anymore. We state that
this needs to be done in our README, but it's probably a testament to how
odd our setup is that it's missed here and there.

Cons:
1. We lose the main selling point of vendoring for our test dependencies
which is that if one of our dependencies is no longer accessible
(deleted, renamed, whatever else) we don't have a local copy included
in our repo. This will increase our dependence on the Go modules proxy
server which seems like a fair tradeoff, and I think we're fine with this for
test dependencies at least.

I've removed the references to this extra step in the README as well as
got rid of the CI step verifying that the vendor dir was up to date. I
don't think we needed the mod=vendor env var either, as since go 1.14 if
there's a top level vendor folder I believe the flag is transparently set
for commands that accept it.


(cherry picked from commit 4e60239)

Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@anmaxvl anmaxvl anmaxvl approved these changes

@katiewasnothere katiewasnothere katiewasnothere approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@dcantah @anmaxvl @katiewasnothere