repo v2.23 prerelease

224 views
Skip to first unread message

Xin Li

unread,
Apr 13, 2022, 1:52:49 PM4/13/22
to Repo and Gerrit Discussion
I've created a new release, but not yet pushed it live.  Instead, people have to opt-in to it by passing --repo-rev=main when running `repo init`.  You can then run `repo selfupdate && repo version` to double check your local state.

So please bang on things and let us know how it goes.  Even "it works" is useful feedback as it means I'm not the only one running it :).
If things look good the rest of this week, I'll publish it next week.

In addition to multi-manifest support (which should be mostly self-contained), this releases also improved git trace2 tracing capability. These features are not enabled by default and needs to be configured, so hopefully this would be uneventful.

Here's the short log since the last release.
d56e2eb (LaMont Jones) manifest_xml: use Superproject to hold XML content
d52ca42 (Daniel Andersson) sync: respect `sync-c` manifest option
a2ff20d (LaMont Jones) manifest_xml: Add Load and Unload methods
55ee304 (LaMont Jones) Fix sub manifest handling
409407a (LaMont Jones) init: add multi-manifest support
d82be3e (LaMont Jones) Move manifest config logic into ManifestProject
9b03f15 (LaMont Jones) project: add ManifestProject.Sync()
9b72cf2 (LaMont Jones) project: Isolate ManifestProject from RepoProject
5d3291d (LaMont Jones) manifest_file must be an absolute path
244c9a7 (Josh Steadmon) trace: allow writing traces to a socket
b308db1 (LaMont Jones) manifest_xml: group for submanifest projects
cc879a9 (LaMont Jones) Add multi-manifest support with <submanifest> element
87cce68 (LaMont Jones) Move local-manifest check to manifest_xml.py
adaa1d8 (LaMont Jones) project.py: pass --recurse-submodules={value}

Cheers,

Mike Frysinger

unread,
Apr 14, 2022, 2:22:39 AM4/14/22
to Xin Li, Repo and Gerrit Discussion
we never pushed v2.22 to stable, so there's a few more commits that will be showing up with v2.23:
cc879a97c3e2 (LaMont Jones) Add multi-manifest support with <submanifest> element
87cce68b28c3 (LaMont Jones) Move local-manifest check to manifest_xml.py
adaa1d8734b9 (LaMont Jones) project.py: pass --recurse-submodules={value}
-mike

--
You received this message because you are subscribed to the Google Groups "Repo tool (git-repo) announcements" group.
To unsubscribe from this group and stop receiving emails from it, send an email to git-repo-annou...@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/git-repo-announce/CAOhzduhsjqaxgP%2Br4iuVPZx_MBt179T%3DsGrOCbBsUNCQVMD_5g%40mail.gmail.com.

Xin Li

unread,
Apr 20, 2022, 4:49:03 PM4/20/22
to Repo and Gerrit Discussion, git-repo...@google.com
I've pushed repo v2.23 to the stable branch and will create another release for testing soon.

Jerry Wehler

unread,
Apr 20, 2022, 8:38:40 PM4/20/22
to Repo and Gerrit Discussion
On every location that updated from v2.21 to v2.23, we have suffered massive outages and in several cases workspace data loss with this version of the tool. We happen to be using this on Windows (sorry, I know) and have been using the --worktree option. Every jenkins node is broken after the first sync. I haven't been able to characterize this yet, other than I can reproduce locally now that I realized it was the repo tool that self updated.

It seems the first repo init/repo sync combo works fine. Then the next time it does a repo sync in the existing workspace, the .repo/manifests project switches to the wrong branch or something, leaving the manifests showing as deleted. It then must try to sync with that and causes problems all over.  Sorry, scant details as I am actively trying to recover now...

-Jerry

Dean Wheatley

unread,
May 31, 2022, 6:12:16 AM5/31/22
to Repo and Gerrit Discussion
We suffered from a similar outage. We've had to advise users and modify agents to lock their repo versions (i.e. use --repo-rev) now to prevent auto-update as we can't trust the stable branch.

LaMont Jones

unread,
Jun 1, 2022, 12:33:30 PM6/1/22
to Dean Wheatley, Repo and Gerrit Discussion
If you have capacity to do so, it would be best to have at least one (separate) workflow that is pinned to `--repo-rev=main`, that verifies that any pre-release version will work when it pushes to stable.  That also helps catch regressions prior to them being released, and closer to the point where they may have been introduced.

We will be looking into making the presubmit changes for repo to be more comprehensive.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/b6526555-3dfe-4df4-956b-c73c5e98ab97n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages