ci/contrib: use separate concurrency group
Run the contrib workflow in its own concurrency group to avoid multiple runs causing conflicting git pushes.
The contrib workflow pushes to the gh-pages branch, and thus is not safe to be run multiple times in parallel. Given that github-actions can stall workflow runs for quite some time, multiple executions can overtake each other. By using concurrency groups, all workflow runs will wait until previous runs completed.
Given that the workflow uses orphan-branches and forced pushes, conflicting workflows will not fail, but might produce outdated data if they overtake each other.
We explicitly disable cancellation to get better diagnostics and more easily find the first possible run that failed. Since these workflow runs are rather fast, and only run on master, cancellation seems not necessary.
Run the contrib workflow in its own concurrency group to avoid multiple
runs causing conflicting git pushes.
The contrib workflow pushes to the gh-pages branch, and thus is not safe
to be run multiple times in parallel. Given that github-actions can
stall workflow runs for quite some time, multiple executions can
overtake each other. By using concurrency groups, all workflow runs will
wait until previous runs completed.
We explicitly disable cancellation to get better diagnostics and more
easily find the first possible run that failed. Since these workflow
runs are rather fast, and only run on master, cancellation seems not
necessary.
The current contrib deploy-hook fails if there is no `gh-pages` branch.
Change the CI order to disregard the old `gh-pages` branch first.
The `contrib` deploy-hook always creates a fresh `gh-pages` commit and
pushes it out. However, currently it relies on the old `gh-pages` branch
to exist, since it does not ignore errors when pruning it. Fortunately,
the code always creates a new orphan branch, since it does not want to
keep history for deployments. Therefore, we can simply use:
`git worktree --orphan -B <branch> <path>`
This will ensure to always create an orphan branch named `<branch>`, and
override an existing branch if it exists (see `-b` vs `-B`). Hence,
there is no need for us to prune the old branch, anymore.
Since we will recreate the branch on every push, we have to explicitly
specify the remote to push to. We no longer set up branch tracking.
The `github.sha` is a merge commit with the parents of latest master
and the head of the pr. Trying to diff the changes from that merge
SHA to base will show all changes that have been made in-between.
And that doesn't seem about right.
We switch to `github.event.pull_request.head.sha` if there is a pr.
See: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/version-bump.20CI.20failing
chore: make credential dependencies platform-specific
### What does this PR try to resolve?
Starting from #11993, we made `cargo-credential-macos-keychain` and `cargo-credential-wincred` able to build on all platforms. However, some of their dependencies are not. This PR turns them into platform specific dependencies to circumvent the situation.
### How should we test and review this PR?
Run the following commands on all platforms Cargo supports.
```
cargo check --workspace --exclude cargo-credential-gnome-secret
```
chore(ci): Enforce cargo-deny in CI
With #11448, we are pulling in a wide and deep dependency tree which makes it harder for us to track what we are pulling in over time.
I've been trying out [`cargo-deny`](https://github.com/EmbarkStudios/cargo-deny) on my projects and wanted to explore how useful it might be for cargo. atm I only have it configured to fail for unexpected licenses. We can also use its warnings to hunt down and remove duplicated dependencies to speed up our builds.
I did also enable advisories. We ignore the failure in a way to not block PRs or even show up as failure in PRs as PR authors are not responsible for dealing with these (unless its a new dep) and it can be intimidating as a contributor to see a failure and have no idea how to resolve it (as authors generally assume CI is green and failures are there fault)
I did not go too much further into what all `cargo-deny` can do; there might be more we can leverage.
This allows to use `gitoxide` for all fetch operations, boosting performance
for fetching the `crates.io` index by a factor of 2.2x, while being consistent
on all platforms.
For trying it, nightly builds of `cargo` can specify `-Zgitoxide=fetch`.
It's also possible to set the `__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1` environment
variable (value matters), which is when `-Zgitoxide=none` can be used
to use `git2` instead.
Limitations
-----------
Note that what follows are current shortcomings that will be addressed in future PRs.
- it's likely that authentication around the `ssh` protocol will work differently in practice
as it uses the `ssh` program.
- clones from `file://` based crates indices will need the `git` binary to serve the locatl repository.
- the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.
We skip failure for advisories on the step, rather than the job, to not
distract contributors in thinking they broke something as that bubbles
up into the PR job summary.
Previously mdbook was bumped in #11646 for contrib.yml worflow
but main.yaml workflow. This makes the two in sync and also
upgrades to the latest 0.4.27. (Though there is nothing really
changed for application users as us)
