Skip to content

Commit 3c3cc0a

Browse files
edburnsedburns
committed
new prompts
1 parent 124c8e2 commit 3c3cc0a

1 file changed

Lines changed: 118 additions & 0 deletions

File tree

‎80-java-monorepo-add-01-remove-before-merge/20260515-prompts.md‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
### 10:11 Prompt
2+
3+
Read the `80-java-monorepo-add-01-remove-before-merge\dd-2989727-move-java-to-monorepo-plan.md` and the two `*-prompts.md` to get the context of what we've been working on.
4+
5+
My current problem is the branch protection rules as tracked in this text in the plan.
6+
7+
```markdown
8+
- [⌛ ] **Confirm branch protection** — will new required status checks be accepted? See https://github.com/github/copilot-sdk-partners/issues/95 .
9+
```
10+
11+
The maintainer has this question:
12+
13+
---
14+
@edburns Can you clarify why we need an action to be able to push directly to main rather than having the action produce a PR?
15+
---
16+
17+
I know there is a good answer for this, but I can't easily articulate it. Can you help me?
18+
19+
### 10:16 Response
20+
21+
The workflow that needs direct-to-main push is `java-publish.yml` (adapted from `publish-maven.yml`), specifically because of how `maven-release-plugin` works.
22+
23+
Here's the articulation:
24+
25+
---
26+
27+
**Why `maven-release-plugin` requires direct push to `main`:**
28+
29+
The Maven Release Plugin performs an **atomic, multi-step commit sequence** as part of its `release:prepare` + `release:perform` lifecycle:
30+
31+
1. Removes `-SNAPSHOT` from pom.xml version → commits as "prepare release vX.Y.Z"
32+
2. Creates a git tag `vX.Y.Z` pointing at that exact commit
33+
3. Bumps pom.xml to next `-SNAPSHOT` version → commits as "prepare for next development iteration"
34+
4. Pushes both commits + tag in one operation
35+
5. `release:perform` then checks out the tag and deploys the artifact to Maven Central
36+
37+
**Why a PR doesn't work here:**
38+
39+
- The **tag must point to the exact commit** with the non-SNAPSHOT version on `main`. If that commit lives on a PR branch, the tag references a commit that isn't on the default branch — Maven Central metadata and `<scm>` URLs become inconsistent.
40+
- A PR introduces a **race condition**: other commits could merge between the release commit and the SNAPSHOT-bump commit, breaking the plugin's assumption of consecutive commits.
41+
- There is **no human decision left to make** — the decision to release was already made when someone triggered the `workflow_dispatch`. The commits are mechanical version bookkeeping, not code changes requiring review.
42+
- The entire operation is **idempotent and reversible** (revert the two commits + delete the tag) if something goes wrong.
43+
44+
This is the standard pattern used by virtually all Maven projects that release via CI (Spring, Apache, Quarkus, etc.). The alternative — manually managing versions and tags outside the plugin — defeats the purpose of using `maven-release-plugin` and introduces more error-prone manual steps.
45+
46+
---
47+
48+
Want me to draft this as a comment you can post directly on the issue?
49+
50+
### 10:17 Prompt
51+
52+
Yes.
53+
54+
### 10:18 Response
55+
56+
Read [](file:///e%3A/workareas/copilot-sdk-java-00/.github/workflows/publish-maven.yml#1-1), lines 1 to 180
57+
58+
Here's a comment you can post:
59+
60+
---
61+
62+
The workflow that needs this is `java-publish.yml` (the Maven release workflow). It uses `maven-release-plugin`, which performs an atomic multi-commit sequence directly on `main`:
63+
64+
1. Removes `-SNAPSHOT` from pom.xml → commits `[maven-release-plugin] prepare release v1.2.3`
65+
2. Creates git tag `v1.2.3` pointing at that exact commit
66+
3. Bumps pom.xml to next `-SNAPSHOT` → commits `[maven-release-plugin] prepare for next development iteration`
67+
4. Pushes both commits + tag in one operation
68+
5. Checks out the tag and deploys the signed artifact to Maven Central
69+
70+
**Why a PR can't substitute here:**
71+
72+
- **The tag must point to a commit on `main`.** Maven Central's POM metadata, `<scm>` URLs, and reproducibility guarantees all assume the tagged commit is on the default branch. A tag pointing at a PR branch commit breaks downstream tooling (Dependabot, IDE source attachment, `mvn scm:changelog`).
73+
- **The two commits must be consecutive.** If a PR is opened between the "set release version" commit and the "set next SNAPSHOT" commit, other PRs could merge in between, meaning `main` would contain a non-SNAPSHOT pom.xml that doesn't correspond to any published artifact — a broken state.
74+
- **There's no remaining human decision.** The release was already authorized by triggering `workflow_dispatch`. The commits are mechanical version bookkeeping, not code changes requiring review.
75+
- **The workflow already has rollback.** If anything fails, it reverts the documentation commit and runs `mvn release:rollback` (lines 168–177 of the current publish-maven.yml).
76+
77+
This is the standard pattern used by Maven projects that release via CI (Spring, Apache, Quarkus, etc.). The `JAVA_RELEASE_TOKEN` PAT with `contents:write` scope is specifically for this use case.
78+
79+
Note: only this one workflow (`java-publish.yml`) needs the bypass. All other Java workflows (`java-sdk-tests.yml`, `java-smoke-test.yml`, `java-codegen-fix.md`, etc.) operate via normal PRs.
80+
81+
---
82+
83+
### 10:21 Prompt
84+
85+
That's close, but let's take the ADR in `docs/adr/adr-002-maven-version-and-reference-implementation-tracking.md` into account regarding tag names.
86+
87+
You stated:
88+
89+
> 2. Creates git tag `v1.2.3` pointing at that exact commit
90+
91+
In our case, per the ADR, the tag would be `v1.2.3-java.0`. To avoid confusion, rewrite your post-ready response using this tag name wherever you need a tag.
92+
93+
### 10:24 Response
94+
95+
Here's the revised comment:
96+
97+
---
98+
99+
The workflow that needs this is `java-publish.yml` (the Maven release workflow). It uses `maven-release-plugin`, which performs an atomic multi-commit sequence directly on `main`:
100+
101+
1. Removes `-SNAPSHOT` from pom.xml → commits `[maven-release-plugin] prepare release v1.2.3-java.0`
102+
2. Creates git tag `v1.2.3-java.0` pointing at that exact commit. See the [ADR](https://github.com/github/copilot-sdk-java/blob/main/docs/adr/adr-002-maven-version-and-reference-implementation-tracking.md).
103+
3. Bumps pom.xml to next `-SNAPSHOT` → commits `[maven-release-plugin] prepare for next development iteration`
104+
4. Pushes both commits + tag in one operation
105+
5. Checks out the tag and deploys the signed artifact to Maven Central
106+
107+
**Why a PR can't substitute here:**
108+
109+
- **The tag must point to a commit on `main`.** Maven Central's POM metadata, `<scm>` URLs, and reproducibility guarantees all assume the tagged commit is on the default branch. A tag pointing at a PR branch commit breaks downstream tooling (Dependabot, IDE source attachment, `mvn scm:changelog`).
110+
- **The two commits must be consecutive.** If a PR is opened between the "set release version" commit and the "set next SNAPSHOT" commit, other PRs could merge in between, meaning `main` would contain a non-SNAPSHOT pom.xml that doesn't correspond to any published artifact — a broken state.
111+
- **There's no remaining human decision.** The release was already authorized by triggering `workflow_dispatch`. The commits are mechanical version bookkeeping, not code changes requiring review.
112+
- **The workflow already has rollback.** If anything fails, it reverts the documentation commit and runs `mvn release:rollback`.
113+
114+
This is the standard pattern used by Maven projects that release via CI (Spring, Apache, Quarkus, etc.). The `JAVA_RELEASE_TOKEN` PAT with `contents:write` scope is specifically for this use case.
115+
116+
Note: only this one workflow (`java-publish.yml`) needs the bypass. All other Java workflows (`java-sdk-tests.yml`, `java-smoke-test.yml`, `java-codegen-fix.md`, etc.) operate via normal PRs.
117+
118+
---

0 commit comments

Comments
 (0)