Hi,

I was able to create a shared environment and 2 other environments but I couldn't find a way to inherit the shared environment by the 2 others. It seems that the parent_environment_id parameter available in runscope api is not available via terraform.
https://www.runscope.com/docs/api/environments

Hi,

I would be really nice if we can add support for the headers in the environment resources instead of having to repeat the same headers in all steps.

see Default Headers
https://www.runscope.com/docs/api-testing/environment-headers/

Thanks
Sylvain L.

In the test step properties before_scripts and scripts, changes to the values are not applied when applying the plan. Unless a new resource is being created from scratch.

The workaround is to destroy the resources and reapply, but then the test history is lost.

As part of the preparation for Terraform v0.12, we would like to migrate all providers to use Go Modules. We plan to continue checking dependencies into vendor/ to remain compatible with existing tooling/CI for a period of time, however go modules will be used for management. Go Modules is the official solution for the go programming language, we understand some providers might not want this change yet, however we encourage providers to begin looking towards the switch as this is how we will be managing all Go projects in the future. Would maintainers please react with 👍 for support, or 👎 if you wish to have this provider omitted from the first wave of pull requests. If your provider is in support, we would ask that you avoid merging any pull requests that mutate the dependencies while the Go Modules PR is open (in fact a total codefreeze would be even more helpful), otherwise we will need to close that PR and re-run go mod init. Once merged, dependencies can be added or updated as follows:

$ GO111MODULE=on go get github.com/some/module@master
$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

GO111MODULE=on might be unnecessary depending on your environment, this example will fetch a module @ master and record it in your project's go.mod and go.sum files. It's a good idea to tidy up afterward and then copy the dependencies into vendor/. To remove dependencies from your project, simply remove all usage from your codebase and run:

$ GO111MODULE=on go mody tidy
$ GO111MODULE=on go mod vendor

Thank you sincerely for all your time, contributions, and cooperation!

Hi,

I cannot figure out how to create other step types like 'pause' and or 'condition'. The documentation seems to indicate that this is possible. Can you provide an example?

Thanks!

Hi there!

Is this provider compatible with Blazemeter? Runscope was integrated into Blazemeter, so not sure if this provider is now defunct, or at least needs renaming?

Issue

When setting a runscope schedule with interval 1d each plan returns a change case the api returns 1.0d causing a new resource.

Versions

terraform v0.13.2
terraform-provider-runscope v0.6.0

Outputs

-/+ resource "runscope_schedule" "schedule" {
        bucket_id      = "xxxxxx"
        environment_id = "xxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx"
      ~ id             = "xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -> (known after apply)
      ~ interval       = "1.0d" -> "1d" # forces replacement
        note           = "Schedule"
        test_id        = "xxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx"

When you try to create anything with a for_each construct with on object with a lot of properties (I think around 20)the provider will hang endlessly. It works for short iterations. For example:

  for_each = module.stack.tests
  bucket_id = module.stack.bucket.id
  step_type = "request"
  test_id = each.value.id
  ...

Output:

runscope_step.internal["naa"]: Still creating... [1m30s elapsed]
runscope_step.internal["ayca"]: Still creating... [1m40s elapsed]
runscope_step.internal["rome"]: Still creating... [1m39s elapsed]
runscope_step.internal["bcaa"]: Still creating... [1m40s elapsed]

Hey,
today I faced the issue, that there is no way to define the order of the steps. And since runscope test steps can depend on each other, therefore the order is important.

Directive depends_on can be used to chain the dependency between tests and it works fine until you need to insert a new test between the existing ones and that doesn't work, because terraform will simply create the new test as last one.

The workaround I figured is to state the test order in the resources name and chain dependencies between each other like:

resource "runscope_step" "create_test_01" {
    depends_on = ["runscope_step.test00"]
    ...
}

resource "runscope_step" "delete_test_02" {
    depends_on = ["runscope_step.create_test_01"]
    ...
}

# ... etc, etc

The serious drawback of such approach is if I want to put the update_test_02 between these two, I would need to rename all the tests after this one, incrementing the order in the resource name like:

resource "runscope_step" "create_test_01" {
    depends_on = ["runscope_step.test00"]
    ...
}

resource "runscope_step" "update_test_02" {
    depends_on = ["runscope_step.create_test_01"]
    ...
}

resource "runscope_step" "delete_test_03" {
    depends_on = ["runscope_step.update_test_02"]
    ...
}

# ... etc, etc

In this case, terraform will remove all the test steps whose names were changed and create them in the correct order. But updating manually the name of all the test isn't a good option.

Do you have any ideas how that can be resolved?

The only viable idea I have is to introduce a new resource type called runscope_steps which actually takes the array of steps and preserves the order.