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.

Sign up for GitHub

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

Jump to bottom

Check links on CI #902

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Check links on CI #902

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cff5ed5
[#4] Use xrefcheck to check links on CI
gromakovsky Jan 23, 2024
f85bc43
Ignore/fix broken links
gromakovsky Jan 23, 2024
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
11 changes: 11 additions & 0 deletions .github/workflows/checks.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,3 +108,14 @@ jobs:

- name: Diff plans
run: GH=1 ./scripts/release/cabal-plan-diff.sh

xrefcheck:

name: Check references
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v4
- uses: serokell/xrefcheck-action@v1
with:
xrefcheck-version: 0.2.2
1 change: 1 addition & 0 deletions docs/website/contents/about-ouroboros/References.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@

The following artifacts influence and/or describe the Consensus implementation.

<!-- xrefcheck: ignore link -->
* [Technical reports](../for-developers/TechnicalReports)
* From the IOG researchers:
* [Ouroboros BFT][ouroboros-bft]
Expand Down
1 change: 1 addition & 0 deletions docs/website/contents/about-ouroboros/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ The Ouroboros research papers that formalize the different protocols (such as Pr
- the honest nodes will all continually and eventually agree on what the best chain is (unless an adversary controls more than half of the network's stake).
- the best chain grows over time.

<!-- xrefcheck: ignore link -->
The Consensus Layer defines the core Consensus components and logic, notably the
Ouroboros protocol. See [References](References).

Expand Down
1 change: 1 addition & 0 deletions docs/website/contents/for-developers/Glossary.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
<!-- xrefcheck: ignore file -->
# Glossary

Notes on the use and maintenance of this glossary:
Expand Down
3 changes: 3 additions & 0 deletions docs/website/contents/for-developers/TechnicalReports.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,15 @@ The following artifacts influence and/or describe the Consensus implementation.

## Consensus and networking

<!-- xrefcheck: ignore link -->
* [The Cardano Consensus and Storage Layer](/pdfs/report.pdf).
* [Introduction to the design of Data Diffusion and Networking of Cardano Shelley][network-report].

## UTxO-HD

<!-- xrefcheck: ignore link -->
* [Storing the Cardano ledger state on disk: analysis and design options (An IOHK technical report)](/pdfs/utxo-db.pdf)
<!-- xrefcheck: ignore link -->
* [Storing the Cardano ledger state on disk: API design concepts (An IOHK technical report)](/pdfs/utxo-db-api.pdf)


Expand Down
2 changes: 1 addition & 1 deletion docs/website/contents/for-developers/VersioningSchemeDecision.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -495,7 +495,7 @@ This rule is so simple that the ✗ for EasyPR is somewhat surpising.
The hidden problem is that this scheme causes spurious merge conflicts among all your PRs.
It would only be possible to merge PRs sequentially and merging one PR requires rebasing every other PR and updating its version number diff (assuming a single target branch).
That usually implies a very poor contributor experience.
(If you're wondering about variations on this, such as "only bump the version if it hasn't already been bumped", see [below](#RisingEdgeCompromises).)
(If you're wondering about variations on this, such as "only bump the version if it hasn't already been bumped", see [below](#possible-risingedge-compromises).)

We assign ✓ for EasyRelease because each release doesn't require any additional work; merely announce the result of the latest PR.
Relatedly, though, we assign ✗ for TypicalReleases because it's unrealistic to release after every PR.
Expand Down