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.

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

improvement: Require k8s provider >=1.11.1 #784

Merged
merged 3 commits into from
Mar 18, 2020

Conversation

dpiddockcmp
Copy link
Contributor

@dpiddockcmp dpiddockcmp commented Mar 12, 2020

PR o'clock

Description

Set the required kubernetes provider version to 1.11.1.

Looks like the original breaking changes in 1.11.0 have been fixed. And hopefully this also resolves the problems people were seeing with the provider randomly trying to modify their default or localhost clusters. Or at least we'll encourage further testing of the provider 😁

Not sure how you want to classify this. It's not really a breaking change but it may cause terraform to fail to init if users have set version = "1.10" like we had in the examples.

Fixes #733
Fixes #713 [probably]

Checklist

@barryib barryib changed the title Require k8s provider >=1.11.1 improvement: Require k8s provider >=1.11.1 Mar 17, 2020
@barryib
Copy link
Member

barryib commented Mar 17, 2020

@dpiddockcmp thanks for your PR. Can you please update your branch according to the new contribution guide and resolve conflicts.

You don't need to modify changelog anymore. It's autogenerated with git-chglog.

@dpiddockcmp
Copy link
Contributor Author

Changes done.

Is this a potentially breaking change? I guess if users set their kubernetes provider version to 1.10.0 to avoid the broken 1.11.0.

@barryib
Copy link
Member

barryib commented Mar 17, 2020

Changes done.

Is this a potentially breaking change? I guess if users set their kubernetes provider version to 1.10.0 to avoid the broken 1.11.0.

Humm does the 1.11.1 breaks anything from 1.10.x ?

@dpiddockcmp
Copy link
Contributor Author

No. There were no breaking changes in the provider. However people who followed the examples and used provider "kubernetes" { version = "1.10" } will get an error on terraform init. Simple enough to fix but a little rude 😅

@barryib
Copy link
Member

barryib commented Mar 18, 2020

Understood. Looking for a way to add breaking change note in commits.

@barryib barryib merged commit 0c1ed0e into terraform-aws-modules:master Mar 18, 2020
@dpiddockcmp dpiddockcmp deleted the k8s-1.11 branch March 19, 2020 11:11
@barryib
Copy link
Member

barryib commented Mar 22, 2020

I merged this with a typo in the commit. I commited Improvement: Require kubernetes provider >=1.11.1 (#784) instead of improvement: Require kubernetes provider >=1.11.1 (#784) (Improvement != improvement). So this commit is not correctly added in the changelog.

I opened this git-chglog/git-chglog#63 but I don't think it'll go somewhere.

I was looking for a way to fix this.

  • Should I amend on master ? (I don't like it)
  • Should I revert this change and Re-open another PR to add this improvement back ?
  • Another solution ?

@dpiddockcmp @max-rocket-internet @antonbabenko please advice.

FWIW, since this, I added a more restrictive configuration for sementic pr #804 and I'll probably add something like https://github.com/tibdex/autosquash to avoid this kind of error happening again.

@antonbabenko
Copy link
Member

I've made the same mistake a couple of days ago and then realized that "improvement" is not even in spec anymore. See here all allowed/supported types - https://github.com/commitizen/conventional-commit-types/blob/master/index.json

Probably "fix" is more universal for something that existed before while "feat" is for new features that didn't exist before.

I think we can safely roll forward and just learn from this. #804 you've made was important and I think it will be enough.

@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants