-
Notifications
You must be signed in to change notification settings - Fork 759
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
Changing auto
init value should not force a repo to be destroy/created
#155
Comments
I'm also experiencing this issue. I think it was not like this in the previous provider version |
@salvianreynaldi so for imports there is an unreleased fix that has been merged but I think in general this is still a problem. Per the docs its only meaningful during creation so we should ignore it rather than force a new resource. In my use case I am using |
@radeksimko any thoughts? I'd really like to see this reverted to the old behavior. |
Hi folks,
Can you explain your use case a bit more? I'm not sure I fully understand the context there. Thanks. |
Sorry been traveling for work. So our use case is that sometimes you want to create a repository without initialization (maybe to copy the history from a public project to a private one and is not a normal fork scenerio) we have a module that used |
Also that has not been released so I am in a broken state for the moment. Can we please revert the change and discuss how to do this without breaking people? |
In the mean time I have had to add:
|
@radeksimko let me know if you need any further clarification Here is a snippet from our module illustrating what we are doing a bit more: resource "github_repository" "repo" {
name = "${var.repo_name}"
description = "${var.repo_description}"
archived = "${var.repo_archived}"
has_downloads = true
has_issues = true
has_wiki = true
homepage_url = "${var.repo_homepage_url}"
private = "${var.private_repo}"
allow_merge_commit = "${var.allow_merge_commit}"
allow_squash_merge = "${var.allow_squash_merge}"
allow_rebase_merge = "${var.allow_rebase_merge}"
has_projects = false
# this automatically creates a commit and pushes to master and is needed
# because your can't add branch protection for an uninitialized repo
# since the branch will not exist yet. It is only relevant during repo
# creation from github api side but we also use it to determine if branch
# protections should be enabled.
auto_init = "${var.auto_init}"
# default_branch = "${var.repo_default_branch}"
topics = "${var.repo_topics}"
# temp for migration purposes only
# lifecycle {
# ignore_changes = ["name", "id", "repository"]
# }
# this is a terrible hack that is needed because of
# https://github.com/terraform-providers/terraform-provider-github/issues/155
# NOTE: that we only do this on the repo and still care about it when looking
# at branch protection
lifecycle {
ignore_changes = ["auto_init"]
}
}
# removed a bunch of irrelevant config
# setup branch protection
resource "github_branch_protection" "master" {
# this is a bit of a hack to allow people to create repositories uninitialized
# and then add branch protection later. The use cases are mostly around needing
# to create "forked" private repositories
count = "${var.auto_init}"
depends_on = [
"github_repository.repo",
"github_team_repository.reviewers",
"github_team_repository.admins",
]
repository = "${var.repo_name}"
branch = "master"
# defaults to true
enforce_admins = "${var.enforce_admins}"
required_status_checks {
# this really should be enabled whereever possible
strict = "${var.require_pull_request_updated_branch}"
# might want to expose this as a var later
contexts = "${var.required_ci_contexts}"
}
required_pull_request_reviews {
dismiss_stale_reviews = "${var.dismiss_stale_reviews}"
# dismissal_users = ["foo-user"]
dismissal_teams = ["${var.dismissal_teams}"]
# intentionally not made a variable
require_code_owner_reviews = true
}
restrictions {
# this should not be used lightly but is an option to allow some "power users"
# additional access without giving them everything. This should most commonly
# done on a per repo basis but thats just me :shrug:
users = "${var.users_that_can_merge}"
# these are names rather than ids
teams = [
"${var.reviewer_teams}",
]
}
}
# removed a bunch of irrelevant config We basically keyed branch protection setup off |
when this is added: https://github.com/terraform-providers/terraform-provider-github/issues/167 I wn't need the hack but I still question why this change made sense. |
I had to disable |
After PR integrations#135, auto_init, license_template, and gitignore_template now all have ForceNew set to true, which means they *will* affect the resource after initial creation. See also PR integrations#148, integrations#155, integrations#164 Signed-off-by: Jordan Evans <jevans@linuxfoundation.org>
This is still an issue, with provider I am unable to import repositories that were created manually, outside of Terraform. When a repository is created manually, the |
@sudoforge in the mean time you can import and it should work with 2.0.0 which contains a partial fix. I am able in my case also use an This needlessly broke users. I would like to propose we only mark parameter objects as immutable in a major release to avoid breaking users pinning via pessimistic version constraints and follow semver to ensure that all changes come in are safe for new and imported resources. Doing so would prevent further issues and forces an operator to make an intentional choice (or lack of pinning) to destroy a resource out of a tainted state object itself. |
@radeksimko @paultyng @tracypholmes any update/feedback? I would like to make a PR to fix this but wanted to see if it would be accepted beforehand since there was some controversy around this. |
Please fix this, I just ran through this fire drill on 200+ repos and had to use the ignore_changes hack. |
Hey all: I have proposed rolling back the changes in #317 but it's up to the maintainers to accept it. So far @radeksimko has been against it without providing any further rationale so I can't really say if this will be accepted or even entertained. |
FWIW, the same problem exists for setting a template on an imported repo. While only relevant during creation, having a template on an imported repo causes the provider to want to re-create the repository based on the template. |
After PR integrations#135, auto_init, license_template, and gitignore_template now all have ForceNew set to true, which means they *will* affect the resource after initial creation. See also PR integrations#148, integrations#155, integrations#164 Signed-off-by: Jordan Evans <jevans@linuxfoundation.org>
Terraform Version
Plugin version
1.3
Affected Resource(s)
Please list the resources as a list, for example:
If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
Terraform Configuration Files
Expected Behavior
auto_init: (Optional) Meaningful only during create; set to true to produce an initial commit in the repository.
To me this should mean that changes to this should ignore any changes. I found in my org that it was something that we used to also toggle branch protection count.
It should ideally note that there was a change but not actually send that request as it does not make sense that someone accidentally or intentionally flipping the value would blow up their code base.
Actual Behavior
marks the resource for deletion/creation
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform plan
terraform apply
auto_init
valueterraform plan
References
The text was updated successfully, but these errors were encountered: