Skip to content

Commit 03cd36c

Browse files
authored
Merge pull request #377 from raboof/restrict-ci-release
Avoid accidentally triggering CI release
2 parents 77eabd3 + 2595863 commit 03cd36c

File tree

2 files changed

+6
-14
lines changed

2 files changed

+6
-14
lines changed

.github/workflows/release.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@ name: Release
22
on:
33
push:
44
branches: [main]
5-
tags: ["*"]
5+
tags: ["v*"]
66
jobs:
77
publish:
88
runs-on: ubuntu-latest

RELEASING.md

Lines changed: 5 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,17 +1,9 @@
1-
## Creating a regular release
1+
## Publishing
22

3-
Creating a release on GitHub triggers a Github Action build that should test, build and publish to Sonatype, and then close and release the repository to Maven Central.
3+
Creating a release on GitHub triggers an Actions build that should test, build, and publish to Sonatype, and then close and release the repository to Maven Central.
44

5-
## Back-releasing for a new Scala version
5+
## Back-publishing for a new Scala version
66

7-
It is often the case when this compiler plugin needs to be released for a newly released Scala version. For this the process is the following:
7+
sbt-ci-release supports this directly.
88

9-
1. Checkout the version that is to be back-released, which would be
10-
* `main`, if no features or bug fixes were merged to the main branch since the latest release. In this case create a tag recording you released from this commit, e.g. `git tag -a -m 'Release 0.19 for Scala 2.12.20' v0.19_2.12.20; git push --tags`.
11-
* tag, if the main branch has unreleased features or bug fixes. In this case you will need to cherry pick the commit that adds support for the new Scala version.
12-
1. Create a file `version.sbt` containing `ThisBuild / version := "0.19"` which sets the version to be back-released. This will override the automatic version derivation from the git history. Alternatively you can `set ThisBuild / version := ...` in the command line.
13-
1. Publish the release by running `SONATYPE_USERNAME=xxx SONATYPE_PASSWORD=xxx sbt clean ++2.12.20 publishSigned sonatypeBundleRelease` (with the appropriate credentials and scala version). You will need Sonatype OSS repository rights to publish under `com.typesafe` organisation.
14-
15-
It would be nice to have a way to backpublish through GitHub Actions instead of using our laptops. If interested in pursuing this possibility, see https://github.com/lightbend/genjavadoc/issues/333 and https://github.com/sbt/sbt-ci-release/issues/102
16-
17-
Note that the instructions above suggest pushing a tag. Pushing the tag may cause sbt-ci-release to attempt to publish incorrect artifacts. It might be better not to push the tag at all? :shrug:
9+
After checking (e.g. with `git diff`) that nothing user-detectable has changed since the last release, push a tag for with the Scala version appended, e.g. to back-publish version 0.19 for Scala 2.13.16, push the tag `[email protected]`.

0 commit comments

Comments
 (0)