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

docs: fix broken link and add link check #1016

Merged
merged 13 commits into from
Aug 29, 2023

Conversation

susanshi
Copy link
Collaborator

@susanshi susanshi commented Aug 23, 2023

Description

What this PR does / why we need it:

  • Fix broken links under /docs
  • Add a automated broken link check for future PRs

Which issue(s) this PR fix (s) when the PR gets merged)*:

Fixes #984

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Helm Chart Change (any edit/addition/update that is necessary for changes merged to the main branch)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

  • Test A
  • Test B

Checklist:

  • Does the affected code have corresponding tests?
  • Are the changes documented, not just with inline documentation, but also with conceptual documentation such as an overview of a new feature, or task-based documentation like a tutorial? Consider if this change should be announced on your project blog.
  • Does this introduce breaking changes that would require an announcement or bumping the major version?
  • Do all new files have appropriate license header?

Post Merge Requirements

  • MAINTAINERS: manually trigger the "Publish Package" workflow after merging any PR that indicates Helm Chart Change

@codecov
Copy link

codecov bot commented Aug 23, 2023

Codecov Report

Patch coverage has no change and project coverage change: -1.20% ⚠️

Comparison is base (dd468dc) 59.58% compared to head (8e4cff6) 58.38%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1016      +/-   ##
==========================================
- Coverage   59.58%   58.38%   -1.20%     
==========================================
  Files          74       92      +18     
  Lines        4498     5529    +1031     
==========================================
+ Hits         2680     3228     +548     
- Misses       1573     1987     +414     
- Partials      245      314      +69     

see 38 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@susanshi susanshi changed the title doc: fix broken link and add link check docs: fix broken link and add link check Aug 25, 2023
@susanshi susanshi marked this pull request as ready for review August 25, 2023 03:28
@@ -90,7 +90,7 @@ The official steps for setting up Workload Identity on AKS can be found [here](h

Ratify resolves registry credentials from [Docker Config Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/#docker-config-secrets) in the cluster. Ratify considers kubernetes secrets in two ways:

1. The configuration can specify a list of `secrets`. Each entry REQUIRES the `secretName` field. The `namespace` field MUST also be provided if the secret does not exist in the namespace Ratify is deployed in. The Ratify helm chart contains a [roles.yaml](https://github.com/deislabs/ratify/blob/main/charts/ratify/templates/roles.yaml) file with role assignments. If a namespace other than Ratify's namespace is provided in the secret list, the user MUST add a new role binding to the cluster role for that new namespace.
1. The configuration can specify a list of `secrets`. Each entry REQUIRES the `secretName` field. The `namespace` field MUST also be provided if the secret does not exist in the namespace Ratify is deployed in. The Ratify helm chart contains a [roles.yaml](https://github.com/deislabs/ratify/blob/main/charts/ratify/templates/??.yaml) file with role assignments. If a namespace other than Ratify's namespace is provided in the secret list, the user MUST add a new role binding to the cluster role for that new namespace.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@akashsinghal , do you know which roles.yaml this should link to?

Copy link
Collaborator

Choose a reason for hiding this comment

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

We have both cluster-role and role defined secret access. In terms of this case, I think we can refer to https://github.com/deislabs/ratify/blob/main/charts/ratify/templates/ratify-manager-role-clusterrole.yaml

@@ -90,7 +90,7 @@ The official steps for setting up Workload Identity on AKS can be found [here](h

Ratify resolves registry credentials from [Docker Config Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/#docker-config-secrets) in the cluster. Ratify considers kubernetes secrets in two ways:

1. The configuration can specify a list of `secrets`. Each entry REQUIRES the `secretName` field. The `namespace` field MUST also be provided if the secret does not exist in the namespace Ratify is deployed in. The Ratify helm chart contains a [roles.yaml](https://github.com/deislabs/ratify/blob/main/charts/ratify/templates/roles.yaml) file with role assignments. If a namespace other than Ratify's namespace is provided in the secret list, the user MUST add a new role binding to the cluster role for that new namespace.
1. The configuration can specify a list of `secrets`. Each entry REQUIRES the `secretName` field. The `namespace` field MUST also be provided if the secret does not exist in the namespace Ratify is deployed in. The Ratify helm chart contains a [roles.yaml](https://github.com/deislabs/ratify/blob/main/charts/ratify/templates/??.yaml) file with role assignments. If a namespace other than Ratify's namespace is provided in the secret list, the user MUST add a new role binding to the cluster role for that new namespace.
Copy link
Collaborator

Choose a reason for hiding this comment

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

We have both cluster-role and role defined secret access. In terms of this case, I think we can refer to https://github.com/deislabs/ratify/blob/main/charts/ratify/templates/ratify-manager-role-clusterrole.yaml

runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we follow the same convention that use digest intead of tag?

@susanshi
Copy link
Collaborator Author

Hi @binbin-li , thanks for the feedback, i ve pushed an update, please review.

@susanshi susanshi enabled auto-merge (squash) August 29, 2023 05:57
@susanshi susanshi merged commit 16945db into ratify-project:main Aug 29, 2023
16 of 17 checks passed
bspaans pushed a commit to bspaans/ratify that referenced this pull request Oct 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

doc: broken links in crd configuration doc
2 participants