Repository navigation
Conversation
|
@vegerot has updated the pull request. You must reimport the pull request before landing. |
|
@vegerot has updated the pull request. You must reimport the pull request before landing. |
|
This pull request has been imported. If you are a Meta employee, you can view this in D123960227. (Because this pull request was imported automatically, there will not be any future comments.) |
|
@vegerot has updated the pull request. You must reimport the pull request before landing. |
### Problem Commit 5027662 ("github: disable failing GitHub CI on push") disabled `.github/workflows/mononoke_linux.yml` on `push` and `pull_request` by setting `on: workflow_dispatch`. Five days later, commit 794e05b regenerated the GitHub Actions workflows and overwrote `.github/workflows/mononoke_linux.yml` back to running on `push` and `pull_request`. Because `build/fbcode_builder/manifests/mononoke` pins `rust_version = 1.91` while unpinned transitive crates (`aws-config@1.12.0`, etc.) now require `rustc 1.94.1`, the workflow fails on every push and pull request. ### Solution Restore `on: workflow_dispatch` in `.github/workflows/mononoke_linux.yml` (matching `edenfs_linux.yml`, `mononoke_mac.yml`, and `mononoke-integration_linux.yml`). Closes facebook#1473 Co-Authored-By: Gemini 4 Argon <noreply@google.com>
`make oss` failed on stable Rust 1.97.1 with: ```text error[E0554]: #![feature] may not be used on stable --> smallvec-1.15.2/src/lib.rs:95: specialization and 8 crates using #![feature(once_cell_try)] ``` ### Problem * Buck builds use a nightly toolchain internally and support these features. * Cargo OSS builds use stable `rustc` by default. * `Cargo.toml` files are `@generated` by `autocargo` from `BUCK` files, so they should not be hand-edited to remove features. ### Solution Setting `RUSTC_BOOTSTRAP=1` in `build.py`'s `cargo_env` allows stable `cargo`/`rustc` to accept these nightly features without requiring users to install a nightly toolchain or override toolchain defaults. Fixes: `cd eden/scm && make -j oss` Closes facebook#1471 Co-Authored-By: Gemini 3.8 Flash <noreply@google.com>
### Problem `build.py` formats versions as `YYYYMMDD_HHMMSS_<hash>`, omitting the legacy `4.4.2_` prefix previously generated by `setup.py`. Because `util.versionagedays()` assumed the date was always at `parts[1]` after splitting on `_`, it parsed the build time (`HHMMSS`) with `%Y%m%d` instead of the date (`YYYYMMDD`): * Python's `strptime` parsed `015833` as Year `0158` AD, Month 3, Day 3. * This caused `sl` to calculate an elapsed time of over 600,000 days (~1,868 years) and emit: ```text hint[old-version]: WARNING! Your version of Sapling is 682491 days old. Please upgrade your installation. ``` ### Solution Search for an 8-digit date string (`len(part) == 8 and part.isdigit()`) across separators (`_`, `.`, `-`, `+`) instead of hardcoding index `1`. This cleanly supports: * `build.py` builds (`YYYYMMDD_HHMMSS_<hash>`) * Legacy `setup.py` builds (`4.4.2_YYYYMMDD_...`) * Release tags (`0.2.YYYYMMDD-...`) Closes facebook#1468 Co-Authored-By: Gemini 3.8 Flash <noreply@google.com>
|
@vegerot has updated the pull request. You must reimport the pull request before landing. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
build.pyformats versions asYYYYMMDD_HHMMSS_<hash>, omitting the legacy4.4.2_prefix previously generated bysetup.py.Because
util.versionagedays()assumed the date was always atparts[1]after splitting on_, it parsed the build time (HHMMSS) with%Y%m%dinstead of the date (YYYYMMDD):strptimeparsed015833as Year0158AD, Month 3, Day 3.slto calculate an elapsed time of over 600,000 days (~1,868 years) and emit:Solution
Search for an 8-digit date string (
len(part) == 8 and part.isdigit()) across separators (_,.,-,+) instead of hardcoding index1. This cleanly supports:build.pybuilds (YYYYMMDD_HHMMSS_<hash>)setup.pybuilds (4.4.2_YYYYMMDD_...)0.2.YYYYMMDD-...)Closes #1468
Co-Authored-By: Gemini 3.8 Flash noreply@google.com
Stack created with Sapling. Best reviewed with ReviewStack.