fix(actions): microk8s action passing correct arguments (#10363)

* fix(actions): microk8s action passing correct arguments Signed-off-by: Amro Misbah <[email protected]> * fix(microk8s): add missing inputs Signed-off-by: Amro Misbah <[email protected]> * fix(actions): add a default JANS_VERSION if not set Signed-off-by: Amro Misbah <[email protected]> * fix(actions): remove comment Signed-off-by: Amro Misbah <[email protected]> --------- Signed-off-by: Amro Misbah <[email protected]> Co-authored-by: Mohammad Abudayyeh <[email protected]>
JanssenProject · Dec 11, 2024 · a1517a0 · a1517a0
1 parent 92cc167
commit a1517a0
Show file tree

Hide file tree

Showing 2 changed files with 13 additions and 8 deletions.
diff --git 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
@@ -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-<version>`.
+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-<version>`.
 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-<version>` 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. 
+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.