Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions Directory.Build.props
Original file line number Diff line number Diff line change
Expand Up @@ -36,10 +36,7 @@
<PackageIcon></PackageIcon>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<PackageProjectUrl>https://github.com/domaindrivendev/Swashbuckle.AspNetCore</PackageProjectUrl>
<!--
TODO Create a generic package README file for the project
<PackageReadmeFile>package-readme.md</PackageReadmeFile>
-->
<PackageReleaseNotes>See $(PackageProjectUrl)/releases for details.</PackageReleaseNotes>
<PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
Expand Down
16 changes: 8 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,9 +9,9 @@ Swashbuckle.AspNetCore

[![NuGet](https://buildstats.info/nuget/Swashbuckle.AspNetCore)](https://www.nuget.org/packages/Swashbuckle.AspNetCore/ "Download Swashbuckle.AspNetCore from NuGet.org")

[Swagger](http://swagger.io) tooling for APIs built with ASP.NET Core. Generate beautiful API documentation, including a UI to explore and test operations, directly from your routes, controllers and models.
[Swagger](https://swagger.io) tooling for APIs built with ASP.NET Core. Generate beautiful API documentation, including a UI to explore and test operations, directly from your routes, controllers and models.

In addition to its [Swagger 2.0 and OpenAPI 3.0](http://swagger.io/specification/) generator, Swashbuckle also provides an embedded version of the awesome [swagger-ui](https://github.com/swagger-api/swagger-ui) that's powered by the generated Swagger JSON. This means you can complement your API with living documentation that's always in sync with the latest code. Best of all, it requires minimal coding and maintenance, allowing you to focus on building an awesome API.
In addition to its [Swagger 2.0 and OpenAPI 3.0](https://swagger.io/specification/) generator, Swashbuckle also provides an embedded version of the awesome [swagger-ui](https://github.com/swagger-api/swagger-ui) that's powered by the generated Swagger JSON. This means you can complement your API with living documentation that's always in sync with the latest code. Best of all, it requires minimal coding and maintenance, allowing you to focus on building an awesome API.

And that's not all ...

Expand Down Expand Up @@ -584,7 +584,7 @@ c.SwaggerDoc("v1",
License = new OpenApiLicense
{
Name = "Apache 2.0",
Url = new Uri("http://www.apache.org/licenses/LICENSE-2.0.html")
Url = new Uri("https://www.apache.org/licenses/LICENSE-2.0.html")
}
}
);
Expand Down Expand Up @@ -670,7 +670,7 @@ If you're using the `SwaggerUI` middleware, you'll need to specify any additiona

### Omit Obsolete Operations and/or Schema Properties ###

The [Swagger spec](http://swagger.io/specification/) includes a `deprecated` flag for indicating that an operation is deprecated and should be refrained from use. The Swagger generator will automatically set this flag if the corresponding action is decorated with the `ObsoleteAttribute`. However, instead of setting a flag, you can configure the generator to ignore obsolete actions altogether:
The [Swagger spec](https://swagger.io/specification/) includes a `deprecated` flag for indicating that an operation is deprecated and should be refrained from use. The Swagger generator will automatically set this flag if the corresponding action is decorated with the `ObsoleteAttribute`. However, instead of setting a flag, you can configure the generator to ignore obsolete actions altogether:

```csharp
services.AddSwaggerGen(c =>
Expand Down Expand Up @@ -731,7 +731,7 @@ public void ConfigureServices(IServiceCollection services)

### Customize Operation Tags (e.g. for UI Grouping) ###

The [Swagger spec](http://swagger.io/specification/) allows one or more "tags" to be assigned to an operation. The Swagger generator will assign the controller name as the default tag. This is important to note if you're using the `SwaggerUI` middleware as it uses this value to group operations.
The [Swagger spec](https://swagger.io/specification/) allows one or more "tags" to be assigned to an operation. The Swagger generator will assign the controller name as the default tag. This is important to note if you're using the `SwaggerUI` middleware as it uses this value to group operations.

You can override the default tag by providing a function that applies tags by convention. For example, the following configuration will tag, and therefore group operations in the UI, by HTTP method:

Expand All @@ -745,7 +745,7 @@ services.AddSwaggerGen(c =>

### Change Operation Sort Order (e.g. for UI Sorting) ###

By default, actions are ordered by assigned tag (see above) before they're grouped into the path-centric, nested structure of the [Swagger spec](http://swagger.io/specification). But, you can change the default ordering of actions with a custom sorting strategy:
By default, actions are ordered by assigned tag (see above) before they're grouped into the path-centric, nested structure of the [Swagger spec](https://swagger.io/specification). But, you can change the default ordering of actions with a custom sorting strategy:

```csharp
services.AddSwaggerGen(c =>
Expand Down Expand Up @@ -850,7 +850,7 @@ _NOTE: Filter pipelines are DI-aware. That is, you can create filters with const

#### Schema Filters ####

Swashbuckle generates a Swagger-flavored [JSONSchema](http://swagger.io/specification/#schemaObject) for every parameter, response and property type that's exposed by your controller actions. Once generated, it passes the schema and type through the list of configured Schema Filters.
Swashbuckle generates a Swagger-flavored [JSONSchema](https://swagger.io/specification/#schemaObject) for every parameter, response and property type that's exposed by your controller actions. Once generated, it passes the schema and type through the list of configured Schema Filters.

The example below adds an AutoRest vendor extension (see https://github.com/Azure/autorest/blob/master/docs/extensions/readme.md#x-ms-enum) to inform the AutoRest tool how enums should be modelled when it generates the API client.

Expand Down Expand Up @@ -927,7 +927,7 @@ services.AddSwaggerGen(c =>
```
#### Document Filters ####

Once an `OpenApiDocument` has been generated, it too can be passed through a set of pre-configured Document Filters. This gives full control to modify the document however you see fit. To ensure you're still returning valid Swagger JSON, you should have a read through the [specification](http://swagger.io/specification/) before using this filter type.
Once an `OpenApiDocument` has been generated, it too can be passed through a set of pre-configured Document Filters. This gives full control to modify the document however you see fit. To ensure you're still returning valid Swagger JSON, you should have a read through the [specification](https://swagger.io/specification/) before using this filter type.

The example below provides a description for any tags that are assigned to operations in the document:

Expand Down
16 changes: 16 additions & 0 deletions package-readme.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Swashbuckle.AspNetCore

[Swagger](https://swagger.io) tooling for APIs built with ASP.NET Core.

Generate beautiful API documentation, including a UI to explore and test operations, directly from your routes, controllers and models.

[![Build status](https://github.com/domaindrivendev/Swashbuckle.AspNetCore/actions/workflows/build.yml/badge.svg?branch=master&event=push)](https://github.com/domaindrivendev/Swashbuckle.AspNetCore/actions?query=workflow%3Abuild+branch%3Amaster+event%3Apush) [![Code coverage](https://codecov.io/gh/domaindrivendev/Swashbuckle.AspNetCore/branch/master/graph/badge.svg)](https://codecov.io/gh/domaindrivendev/Swashbuckle.AspNetCore)
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the added value to add Build status and Code coverage badges to the package readme of the master branch?
When I look for a package and see the readme, I don't need to know if the master branch failed to build. It could be interesting to know what the code coverage is for the specific package version, but it wouldn't influence my decision to use a package very much (except perhaps if the coverage is 0%...)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Just because it's already in the README and it still renders correctly in NuGet's Content Security Policy. I've essentially kept the "top" of the repo README, but with everything their CSP policy forbids, such as the OpenSSF Scorecard badge.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The coverage also wouldn't be "a" version. It would just be "now". Aligning that as burned-in content in the package is too much engineering effort.

Copy link
Contributor

Choose a reason for hiding this comment

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

The coverage also wouldn't be "a" version. It would just be "now". Aligning that as burned-in content in the package is too much engineering effort.

Possibly it might be done using the /tags/{versionnumber} url, but indeed the effort doesn't really warrant that change.

Anyways, I just wanted to raise the question of the necessity for these badges in the package readme.


## Release notes

- The repository's [releases](https://github.com/domaindrivendev/Swashbuckle.AspNetCore/releases) describes changes by release.
- We tag Pull Requests and Issues with [milestones](https://github.com/domaindrivendev/Swashbuckle.AspNetCore/milestones) which match to NuGet package release numbers.

## Documentation and Samples

Documentation, and samples, for using Swashbuckle.AspNetCore can be found in the repository's [README](https://github.com/domaindrivendev/Swashbuckle.AspNetCore#readme).