Split project data source#119
Conversation
The `circleci_project` data source currently fetches both project information and project settings, primarily the latter. Reading project settings requires permission to trigger builds, so it cannot be done by a user with only read-only permissions. Having a way to look up project information (especially project slug -> project ID mapping) is quite useful, and should be doable with a read-only user. I went with splitting the project settings out to a separate data source, and keeping `circleci_project` to just the project information. This is a breaking change, but since we're still pre-1.0, I think now is a good time to make those changes. Since this is just a data source, fixing the breaking change is also not too complicated, compared to a resource with state that needs to be ported over.
| func (d *ProjectDataSource) Schema(_ context.Context, _ datasource.SchemaRequest, resp *datasource.SchemaResponse) { | ||
| resp.Schema = schema.Schema{ | ||
| MarkdownDescription: "Fetches information about a CircleCI project and its settings.", | ||
| Description: "Fetches information about a CircleCI project.", |
There was a problem hiding this comment.
Any particular reason why you are setting Description instead of MarkdownDescription? All the other files use MarkdownDescription as far as I can tell
There was a problem hiding this comment.
I based it off the documentation, which states:
At the moment, if the
MarkdownDescriptionproperty is set it will always be used instead of theDescriptionproperty. It is possible that a different strategy may be employed in the future to surface descriptions to other tooling in a different format, so we recommend specifying both fields.
So it seems like the "correct" thing to do is to set Description or both MarkdownDescription, but not only MarkdownDescription. Since most of the fields don't use any markdown formatting at all, I went with Description for most of them, and added an additional MarkdownDescription field to the few fields that have a bit of formatting.
There was a problem hiding this comment.
(But I can revert that if you'd like, and maybe pull it into a separate PR and do it for all the various resources and data soruces, I just decided it was a decent opportunity to check that these data sources were following the documented recommendations)
There was a problem hiding this comment.
yeah, reverting it and possibly making a separate PR for updating the field in the resources sounds reasonable to me.
2 participants
The
circleci_projectdata source currently fetches both project information and project settings, primarily the latter.Reading project settings requires permission to trigger builds, so it cannot be done by a user with only read-only permissions.
Having a way to look up project information (especially project slug -> project ID mapping) is quite useful, and should be doable with a read-only user.
I went with splitting the project settings out to a separate data source, and keeping
circleci_projectto just the project information.This is a breaking change, but since we're still pre-1.0, I think now is a good time to make those changes. Since this is just a data source, fixing the breaking change is also not too complicated, compared to a resource with state that needs to be ported over.
I ran the acceptance tests for these two data sources locally: