diff --git a/.github/workflows/test-microk8s.yml b/.github/workflows/test-microk8s.yml index 5f5f70413ae..6f0e218c376 100644 --- a/.github/workflows/test-microk8s.yml +++ b/.github/workflows/test-microk8s.yml @@ -2,19 +2,22 @@ name: microk8s on: push: branches: - - master - main paths: - "charts/**" - "automation/startjanssendemo.sh" pull_request: branches: - - master - main paths: - "charts/**" - "automation/startjanssendemo.sh" workflow_dispatch: + inputs: + jans_version: + description: 'Janssen helm chart version' + required: true + default: '0.0.0-nightly' permissions: contents: read @@ -24,7 +27,7 @@ jobs: max-parallel: 6 matrix: istio: ["true", "false"] - persistence-backends: ["MYSQL"] + persistence-backends: ["MYSQL", "PGSQL"] fail-fast: false runs-on: ubuntu-latest steps: @@ -39,7 +42,9 @@ jobs: - name: Test dev setup id: start_up_script run: | - ip=$(ifconfig eth0 | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1') + ip=$(curl ipinfo.io/ip) chmod u+x automation/startjanssendemo.sh - sudo bash ./automation/startjanssendemo.sh demoexample.jans.io ${{ matrix.persistence-backends }} true $ip ${{ matrix.istio }} "--devel" + JANS_VERSION=${{ github.event.inputs.jans_version }} + JANS_VERSION=${JANS_VERSION:-"0.0.0-nightly"} + sudo bash ./automation/startjanssendemo.sh demoexample.jans.io ${{ matrix.persistence-backends }} $JANS_VERSION $ip true ${{ matrix.istio }} sudo bash ./automation/analyze_test_microk8s_setup.sh "${{ secrets.MOAUTO_ROCKETCHAT_TOKEN }}" "${{ secrets.MOAUTO_ROCKETCHAT_ID }}" ${{ matrix.persistence-backends }} diff --git a/docs/contribute/ci-cd/release-process.md b/docs/contribute/ci-cd/release-process.md index d2b2be45794..37bb6f4e4e4 100644 --- a/docs/contribute/ci-cd/release-process.md +++ b/docs/contribute/ci-cd/release-process.md @@ -13,13 +13,13 @@ The release process starts on scheduled times detailed in the [milestones](https 1. **Release Planning**: The release manager creates a release plan that normally includes the release date, the version number, and the main features that will be included in the release. The release plan is shared with the team for review and feedback. 2. **Feature Freeze**: The release manager announces the feature freeze date. After this date, no new features will be added to the release. The team focuses on fixing bugs and improving the quality of the release. QA starts testing the release. 3. **Code Freeze**: The release manager announces the code freeze date. After this date, no new code will be added to the release. The team focuses on fixing bugs and improving the quality of the release. QA team verifies testing the release. -4. **Release Candidate**: The release manager creates a release candidate and shares it with the team for testing. The team tests the release candidate and reports any issues found. The release manager fixes the issues and creates a new release candidate. This process continues until the release candidate is stable. This normally done via a PR process and release branch following the structure `release-`. +4. **Release Candidate**: The release manager creates a release candidate and shares it with the team for testing. The team tests the release candidate and reports any issues found. The release manager fixes the issues and creates a new release candidate. This process continues until the release candidate is stable. This is normally done via a PR process and release branch following the structure `release-`. 5. **Release**: The release manager creates the final release and shares it with the team. The team tests the final release and reports any issues found. The release manager fixes the issues and creates a new release. This process continues until the final release is stable. -6. **Release Notes**: The release manager creates the release notes and shares them with the team.Th The release notes include the version number, the main features included in the release, and any known issues. The release notes are shared with the community. This process is automated and picked up through conventional commits developers submit. +6. **Release Notes**: The release manager creates the release notes and shares them with the team. The release notes include the version number, the main features included in the release, and any known issues. The release notes are shared with the community. This process is automated and picked up through conventional commits developers submit. 7. **Release Announcement**: The release manager announces the release to the community. The announcement includes the version number, the main features included in the release, and any known issues. The announcement is shared on the Janssen website, the Janssen blog, and social media. The release manager also sends an email to the Janssen mailing list. 8. **Post-Release**: The release manager monitors the release and addresses any issues that arise. The team continues to work on the next release. 9. **Release Retrospective**: The release manager conducts a retrospective to review the release process and identify areas for improvement. The team provides feedback on the release process. The release manager uses this feedback to improve the release process for future releases. 10. **Next Release Planning**: The release manager starts planning the next release. The process starts again from step 1. A branch `release-` is created for the next dev and snapshot release with a similar process from step 1 and is merged into `main`. # Future plans -We are planning a full move to SemVer for all Janssen projects that will be scheduled bi-weekly. In this move the google release please Github workflow will be activated to automatically release the projects according to the conventional commits submitted. \ No newline at end of file +We are planning a full move to SemVer for all Janssen projects that will be scheduled bi-weekly. In this move, the Google `release-please` GitHub workflow will be activated to automatically release the projects according to the conventional commits submitted. \ No newline at end of file