We excluded the packages in #13731 but that just means they fell into
the default logic, rather than being ignored (see #13835). This at
least made it easier to reject the change.
This should prevent the PR from being created.
This adds some tests to ensure that the database used in the global
cache tracker stays compatible across versions. These tests work by
using rustup to run both the current cargo and the stable cargo, and
verifying that when switching versions, everything works as expected.
With #13254, we found MSRV updating is broken.
PR #12775 is the last MSRV we got.
That was merged before #12654 and #13106.
That makes #12654 the most likely culprit.
Looking at the logs:
```
DEBUG: Matched 24 file(s) for manager regex: Cargo.toml, benches/benchsuite/Cargo.toml, benches/capture/Cargo.toml, crates/cargo-platform/Cargo.toml, crates/cargo-test-macro/Cargo.toml, crates/cargo-test-support/Cargo.toml, crates/cargo-test-support/containers/apache/bar/Cargo.toml, crates/cargo-test-support/containers/sshd/bar/Cargo.toml, crates/cargo-util-schemas/Cargo.toml, crates/cargo-util/Cargo.toml, crates/crates-io/Cargo.toml, crates/home/Cargo.toml, crates/mdman/Cargo.toml, crates/resolver-tests/Cargo.toml, crates/rustfix/Cargo.toml, crates/semver-check/Cargo.toml, crates/xtask-build-man/Cargo.toml, crates/xtask-bump-check/Cargo.toml, crates/xtask-stale-label/Cargo.toml, credential/cargo-credential-1password/Cargo.toml, credential/cargo-credential-libsecret/Cargo.toml, credential/cargo-credential-macos-keychain/Cargo.toml, credential/cargo-credential-wincred/Cargo.toml, credential/cargo-credential/Cargo.toml
...
DEBUG: manager extract durations (ms)
{
"managers": {
"dockerfile": 30,
"github-actions": 38,
"regex": 386,
"cargo": 855
}
}
DEBUG: Found cargo package files
DEBUG: Found dockerfile package files
DEBUG: Found github-actions package files
DEBUG: Found 25 package file(s)
```
Our regex managers have the files matched
but no regex manager packages are found.
I think this means that the name association failed or the regex within
the file content failed.
The differences between cargo and my other projects
- Use of `:`
- `depNameTemplate`
- Presence of `\b`
As a first attempt, I'm going to switch `\b` to `\\b` to be like the
other escaped regex values.
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
I've been having some repos not updated lately. RenovateBot project's theory is
that its because RenovateBot is scheduled to run once every 3 hours and
checks the schedule at that point while the schedules I use only offers
an exact 3 hour window, making this a race condition. The schedule
originally came from RenovateBot but they changed their polling
schedule.
See https://github.com/renovatebot/renovate/discussions/23642#discussioncomment-6618560
This will update `Cargo.toml` and `Cargo.lock` at the same time. By
default, all dependencies will be updated, so we pull out the compatible
dependencies into a consolidated PR.
This starts off with the dependency dashboard and automerging being
disabled but explicitly specified to call attention to the potential for
this. We can evaluate these later.
Ed Page
Weihang Lo
Eric Huss
Sebastian Thiel
Urgau
renovate[bot]
bors
David Rheinsberg
Arlo Siemsen