From c4315e9224901f3773e7a05442ce7dbb54da5f64 Mon Sep 17 00:00:00 2001 From: Zachary Brown Date: Tue, 7 Jan 2025 14:46:58 -0800 Subject: [PATCH] ci: rc versions into apt repo --- .github/workflows/build.yaml | 9 ++++++--- README.md | 26 +++++++++++++++++++++++--- 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml index 0721181..cde38b4 100644 --- a/.github/workflows/build.yaml +++ b/.github/workflows/build.yaml @@ -378,7 +378,7 @@ jobs: # zip -r ${APP_NAME}-macos-binary-x64-${{ steps.tag-name.outputs.TAGNAME }}.zip ${APP_NAME}-macos-x64 # RC release should not be set as latest - - name: Decide if release should be set as latest + - name: Decide if release should be set as latest and set glue project id: is_latest shell: bash run: | @@ -390,14 +390,17 @@ jobs: echo "release candidate tag matched" IS_LATEST='false' IS_PRERELEASE='true' + GLUE_PROJECT='climate-tokenization-test' else echo "main branch release matched" IS_LATEST='true' IS_PRERELEASE='false' + GLUE_PROJECT='climate-tokenization' fi echo "IS_LATEST=${IS_LATEST}" >> "$GITHUB_OUTPUT" echo "IS_PRERELEASE=${IS_PRERELEASE}" >> "$GITHUB_OUTPUT" + echo "GLUE_PROJECT=${GLUE_PROJECT}" >> "$GITHUB_OUTPUT" - name: Release uses: softprops/action-gh-release@v2 @@ -419,10 +422,10 @@ jobs: echo "REPO_NAME=$(echo "$GITHUB_REPOSITORY" | cut -d "/" -f 2)" >>$GITHUB_OUTPUT - name: Trigger apt repo update - if: startsWith(github.ref, 'refs/tags/') && !contains( github.ref, '-rc') + if: startsWith(github.ref, 'refs/tags/') uses: Chia-Network/actions/github/glue@main with: json_data: '{"climate_tokenization_repo":"${{ steps.repo-name.outputs.REPO_NAME }}","application_name":"[\"${{ env.APP_NAME }}\"]","release_version":"${{ steps.tag-name.outputs.TAGNAME }}","add_debian_version":"true","arm64":"available"}' glue_url: ${{ secrets.GLUE_API_URL }} - glue_project: "climate-tokenization" + glue_project: "${{steps.is_latest.outputs.GLUE_PROJECT}}" glue_path: "trigger" diff --git a/README.md b/README.md index 5cbbe28..c8c86a9 100644 --- a/README.md +++ b/README.md @@ -66,11 +66,31 @@ For ``, enter the user that Chia runs as (the user with the `.chia` di sudo systemctl enable core-registry-api@ ``` -### Ports, Networking, and Security +#### Pre-release Versions + +Experimental code is released with a "release candidate" naming convention and can be found on the [releases](/releases) page with `-rc` in the version number. Not all of the release candidates will be stable and caution should be used. + +Release candidates can be installed via `apt` using the instructions (above)[#debian-based-linux-distros-ubuntu-mint-etc] except replace step 3 with the following: + +``` +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/climate-tokenization-test/debian/ stable main" | sudo tee /etc/apt/sources.list.d/climate-tokenization-test.list > /dev/null +``` + +If both the stable and release-candidate repos are added, `apt` can switch between versions installed using by appending `=` to the install command: + +``` +apt install core-registry-api=1.0.39 +apt install core-registry-api=1.0.39-rc3 +apt install core-registry-api=1.0.1 +``` + +Without specifying the version number, `apt` will install the latest release candidate if it exists, which might not always be desired. + +## Ports, Networking, and Security To configure the services in the unified Core Registry API, please see the documentation of the individual applications listed at the top of this README. -### Contributing +## Contributing All branches should be created from the `develop` branch and not from `main`. All pull requests should be made against the `develop` branch, unless it is a new release. The `develop` branch will be merged into the `main` branch to create a release. Automation in the CI will create the [release](https://github.com/Chia-Network/core-registry-api/releases) and attach the installation files to it automatically whenever code is merged to `main`. Additionally, the changelog will automatically be updated in the `main` branch. Therefore, the `main` branch should always be a representation of the latest released code. @@ -99,7 +119,7 @@ The first part of this is the commit "type". The most common types are "feat" fo ​ The "subject" of the commit follows. It should be a short indication of the change. The commit convention prefers that this is written in the present-imperative tense. -### Versioning +## Versioning This project mostly adheres to semantic versioning. The version specified in `package.json` will be used by the ci to create the new release in Github so it is important to set that correctly. The major version (version 1.0, 2.0, etc) should only be changed when the data model changes and the API goes from v1 to v2. Minor version changes (version 1.2 to 1.3, etc) are for breaking or substantial changes, usually requiring some action on the user's part.