chore(release): v1.0.0 ✨

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,11 +4,8 @@
 - [ ] Bug fix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
 - [ ] Breaking change (fix or feature that would cause existing functionality to change)
-- [ ] My code follows the code style of this project.
-- [ ] My change requires a change to the documentation.
 - [ ] I have updated the documentation accordingly.
 - [ ] I have added tests to cover my changes.
-- [ ] All new and existing tests passed.
 
 
 ### A description of the changes proposed in the Pull Request

.github/codeql/codeql-config.yml

@@ -0,0 +1,7 @@
+paths:
+  - "src"
+paths-ignore:
+  - "src/__tests__/**/*.js"
+  - "src/__tests__/**/*.ts"
+  - "src/__tests__/**/*.jsx"
+  - "src/__tests__/**/*.tsx"

.github/workflows/dispatch-integration-test.yml

@@ -0,0 +1,23 @@
+name: Run if-check on requested branch
+
+on: 
+  workflow_dispatch: 
+
+jobs:
+  run:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 18
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: npm install
+
+      - name: Run integration tests
+        run: npm run if-check -- -d manifests/outputs

.github/workflows/nodejs-ci.yml

@@ -3,21 +3,83 @@ on: push
 jobs:
   build:
     runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write # this allows to show carbon and energy data table in PRs
     steps:
+      - name: Eco CI Energy Estimation - Initialize
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: start-measurement
+        continue-on-error: true
+
       - name: Checkout code
         uses: actions/checkout@v4
 
+      - name: Eco CI Energy Estimation - Get Measurement
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: get-measurement
+          label: "checkout"
+        continue-on-error: true
+
       - name: Set up Node.js
         uses: actions/setup-node@v4
         with:
           node-version: 18
           cache: 'npm'
 
+      - name: Eco CI Energy Estimation - Get Measurement
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: get-measurement
+          label: "setup node"
+        continue-on-error: true
+
+
       - name: Install dependencies
         run: npm install
 
+      - name: Eco CI Energy Estimation - Get Measurement
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: get-measurement
+          label: "npm install"
+        continue-on-error: true
+
+
       - name: Run lint
         run: npm run lint
+
+      - name: Eco CI Energy Estimation - Get Measurement
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: get-measurement
+          label: "npm run lint"
+        continue-on-error: true
+
 
-      - name: Run tests
+      - name: Run unit tests
         run: npm run test --silent
+
+      - name: Eco CI Energy Estimation - Get Measurement
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: get-measurement
+          label: "npm run test"
+        continue-on-error: true
+
+      - name: Eco CI Energy Estimation - End Measurement
+        uses: green-coding-solutions/[email protected]
+
+        with:
+          task: display-results
+          send-data: true
+          pr-comment: true
+        continue-on-error: true
+

.github/workflows/release-commit.yml

@@ -4,29 +4,54 @@ on:
     types: [published]
 
 env: 
-  PR_BRANCH_NAME: release-${{github.event.release.tag_name}}
+  PR_BRANCH_NAME: release-${{ github.event.release.tag_name }}
+  PRE_RELEASE: ${{ github.event.release.prerelease}}
 
 jobs:
-  build:
+  unit-tests:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
+        with:
+          ref: ${{ github.ref }}
 
       - name: Setup Node.js
         uses: actions/setup-node@v4
         with:
           node-version: 18
+          registry-url: https://registry.npmjs.org/
 
       - name: Install dependencies
         run: npm ci
 
       - name: Run unit tests
         run: npm test
 
-  create-release-commit:
-    needs: build
+  integration-tests:
     runs-on: ubuntu-latest
+    needs: unit-tests
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          ref: ${{ github.ref }}
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 18
+          registry-url: https://registry.npmjs.org/
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Run integration tests
+        run: npm run if-check -- -d manifests/outputs
+
+  publish:
+    runs-on: ubuntu-latest
+    needs: integration-tests
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
@@ -48,19 +73,25 @@ jobs:
       - name: Initialize git user name
         run: git config --global user.name "Release commit workflow"
 
-      - name: Create release branch
+      - name: Fetch latest changes
+        run: git fetch --all
+
+      - name: Checkout to release branch if it's not a pre-release
+        if: ${{!env.PRE_RELEASE}}
+        run: git checkout ${{ vars.RELEASE_BRANCH_NAME }}
+
+      - name: Checkout to current release branch to create PR from
         run: |
           git checkout -b $PR_BRANCH_NAME
           git push --set-upstream origin $PR_BRANCH_NAME
-          echo "branch=$PR_BRANCH_NAME" >> $GITHUB_ENV
         
       - name: Bump version and push changes using release-it
         run: |
-          npm run release -- --ci ${{github.event.release.tag_name}}
+          npm run release -- --ci ${{ github.event.release.tag_name }}
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Create pull request
-        run: gh pr create -B release -H $PR_BRANCH_NAME --title "Release ${{github.event.release.tag_name}}" --body "${{github.event.release.body}}"
+        run: gh pr create -B ${{ vars.RELEASE_BRANCH_NAME }} -H $PR_BRANCH_NAME --title "Release ${{github.event.release.tag_name}}" --body "${{github.event.release.body}}"
         env:
-            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/release-publish.yml

@@ -5,25 +5,12 @@ on:
       - release
 
 jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 18
-      - run: npm ci
-      - run: npm test
-
-  publish-npm:
-    needs: build
+  release-publish-npm:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
-        with:
-          ref: main
-
+
       - name: Setup Node.js
         uses: actions/setup-node@v4
         with:
@@ -33,6 +20,12 @@ jobs:
       - name: Install dependencies
         run: npm ci
 
+      - name: Run unit tests
+        run: npm test
+
+      - name: Run integration tests
+        run: npm run if-check -- -d manifests/outputs
+
       - name: Initialize git user email
         run: git config --global user.email "${{ env.RELEASE_USER_EMAIL }}"
 
@@ -60,6 +53,11 @@ jobs:
           echo "LATEST_RELEASE_NAME=$LATEST_RELEASE_NAME" >> $GITHUB_ENV
           echo "IS_PRE_RELEASE=$IS_PRE_RELEASE" >> $GITHUB_ENV
 
+      - name: Fetch and checkout to release branch
+        run: |
+          git fetch --all
+          git checkout ${{ vars.RELEASE_BRANCH_NAME }}
+
       - name: Publish to npm (pre-release)
         if: env.IS_PRE_RELEASE == 'true'
         run: npm publish --tag beta
@@ -72,4 +70,4 @@ jobs:
         run: npm publish
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

CONTRIBUTING.md

@@ -8,6 +8,7 @@ The following document is a rule set of guidelines for contributing.
 
 - [What and when to contribute](#what-and-when-to-contribute)
 - [Reporting bugs](#reporting-bugs)
+- [Disclosing vulnerabilities](#disclosing-vulnerabilities)
 - [Code Contributions](#code-contributions)
   - [Step 1: Fork](#step-1-fork)
   - [Step 2: Branch](#step-2-branch)
@@ -20,31 +21,33 @@ The following document is a rule set of guidelines for contributing.
   - [Naming conventions](#naming-conventions)
     - [Documentation](#documentation)
   - [Writing tests](#writing-tests)
+  - [How to report issues (bugs)](#how-to-report-issues-bugs)
 
 ## What and when to contribute
 
-You can contribute anything to the IF, but we are likely to close out unsolicited PRs without merging them. Our issue board is completely open and we have tags (`help-wanted`, `good-first-issue`) to help contributors to choose tasks to work on. We recommend speaking to the core team on Github before starting working on an issue. You can do this by raising an issue or commenting on an existing issue. This helps us to direct your energy in directions that are aligned with our roadmap, prevent multiple people working on the same task, and better manage our board. This all makes it much more likely that your work will get merged.
+You can contribute anything to the IF, but we are likely to close out unsolicited PRs without merging them. Our issue board is completely open and we have tags (`core-only`, `good-first-issue`) to help contributors to choose tasks to work on. If an issue is unassigned and does not have the `core-only` label, it is available to work on. We recommend speaking to the core team on Github before starting working on an issue. You can do this by commenting on an existing issue or discussion thread or starting a new one if appropriate. This helps us to direct your energy in directions that are aligned with our roadmap, prevent multiple people working on the same task, and better manage our board. This all makes it much more likely that your work will get merged.
+
+You can also contribute by participating in discussions on our mailing list at [[email protected]](https://groups.google.com/u/1/a/greensoftware.foundation/g/if-community). We send out weekly updates that includes what we've shipped, what we're working on and how you can get involved each week.
 
 ## Reporting bugs
 
-We appreciate bug reports! If you experience an issue with IF or one of our plugins, you can report it using our bug reporting template. To do this:
+We appreciate bug reports! If you experience an issue with IF, you can report it using our bug reporting template. To do this:
 
-1. Go to the [IF repository](https://github.com/Green-Software-Foundation/if) (or [plugin repository](https://github.com/Green-Software-Foundation/if-plugins) if you bug relates to a specific plugin)
+1. Go to the [IF repository](https://github.com/Green-Software-Foundation/if)
 2. Click on the `Issues` tab
 3. Click on `Create New Issue` and select the `Bug Report` template.
 4. Fill out the requested information.
 
-The more detailed information you provide in the bug report, the easier it will be for us to diagnose, triage and resolve your issue. We ask for some simple information about your issue, including a description of the error, the expected behaviour, the actual behaviour and the stepos we can take to reproduce the error in our local environments. We also then prompt you to provide a link to [Stackblitz](https://stackblitz.com/) or a similar online environment where we can run your manifest and observe the error. If you prefer *not* to send a link, we would appreciate a copy of the manifest file that you ran to produce the error, information about your runtime environment and any additional code that's required to reproduce the error. This is all designed to enable us to reproduce the same error and debug it for you as quickly as possible.
+The more detailed information you provide in the bug report, the easier it will be for us to diagnose, triage, and resolve your issue. We ask for some simple information about your issue, including a description of the error, the expected behaviour, the actual behaviour and the steps we can take to reproduce the error in our local environments. We also then prompt you to provide a link to [Stackblitz](https://stackblitz.com/) or a similar online environment where we can run your manifest and observe the error. If you prefer *not* to send a link, we would appreciate a copy of the manifest file that you ran to produce the error, information about your runtime environment, and any additional code that's required to reproduce the error. This is all designed to enable us to reproduce the same error and debug it for you as quickly as possible.
 
-Once a suitably detailed bug report exists, we will triage it. We hold weekly triage calls on Tuesdays. In most cases, the triage call will be the core team's first interaction with the bug, although in some cases we may engage asynchronously in advance of the call. Triage means that the core team will examine the issue and assign an urgency label - either Low, Medium or High. 
+Once a suitably detailed bug report exists, we will triage it. Triage means that the core team will examine the issue and assign an urgency label - either Low, Medium or High. 
 
 The assessment rubric is as follows:
 
 |                                                                                                                        | Consequence                                                                              | Severity |
 | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | -------- |
 | Bugs in IF core leading to incorrect calculations                                                                      | unusable framework                                                                       | 5        |
-| Bugs in if-plugins leading to incorrect calculations                                                                   | core pathways fail, IF very limited in functionality                                     | 5        |
-| Bugs in if-unofficial-pluginsd leading to incorrect calculations                                                       | Third party plugins harder to use, limits IF to standard lib                             | 3        |
+| Bugs in builtins leading to incorrect calculations                                                                     | core pathways fail, IF very limited in functionality                                     | 5        |
 | Bugs in template                                                                                                       | Harder to build plugins, ecosystem growth is impacted                                    | 2        |
 | Bugs in docs                                                                                                           | product does not match expectation, hard to debug, frustration, loss of adoption         | 2        |
 | Security flaw: privacy related                                                                                         | leak user data, unlikely to achieve adoption in serious orgs                             | 5        |
@@ -67,7 +70,7 @@ The mapping of severity to label is as follows:
 | 4        | H     |
 | 5        | H     |
 
-During the bug triage we will also discuss a remediation plan for the bug. This will be communicated in the comments on the bug report. For high urgency bugs, the fix will be implemented as soon as possible, maybe reorganizing our current work to accommodate it. For medium priority bugs, we will schedule the fix in the next available sprint. Low priority bugs will be backlogged and addressed when there is developer time available. Low priority bugs will also be tagged `help-wanted` so that they can be addressed by community members.
+The fix will be implemented for high-urgency bugs as soon as possible. Low priority bugs will be backlogged and addressed when there is developer time available. Low priority bugs will also be tagged `help-wanted` so that they can be addressed by community members.
 
 Not every bug will be fixed. We may decide *not* to fix a bug in cases such as:
 
@@ -78,6 +81,18 @@ Not every bug will be fixed. We may decide *not* to fix a bug in cases such as:
 
 The bug will be labelled `fix-now`, `fix-later` or `wont-fix` to reflect our remediation plan and details will be provided in issue comments.
 
+## Disclosing vulnerabilities
+
+If you discover a security vulnerability in IF, please report it to [email protected].
+
+Include the following information:
+
+- description of the issue
+- steps to reproduce
+- steps to fix, if known
+
+The IF team will respond as quickly as possible. Post-graduation there will be no full-time development team, but GSF staff will aim to get the vulnerability patched as quickly as possible, aiming for <=14 day response time.
+
 
 ## Code Contributions
 
@@ -153,7 +168,7 @@ $ git push origin <topic-branch-name>
 
 ### Step 6: Pull Request
 
-Open a Pull Request from your fork of the repository to the `dev` branch of the IF repository with a clear title and description according to [template](.github/PULL_REQUEST_TEMPLATE.md).
+Open a Pull Request from your fork of the repository to the `main` branch of the IF repository with a clear title and description according to [template](.github/PULL_REQUEST_TEMPLATE.md).
 
 Pull requests will not be reviewed unless they pass all CI. This includes a lint check and running our unit tests.
 
@@ -176,7 +191,7 @@ We prefer not to use abbreviations of contractions in parameter names.
 
 Using fully descriptive names makes the code more readable, which in turn helps reviewers and anyone else aiming to understand how the plugin works. 
 
-It also helps to avoid ambiguity and naming collisions within and across plugins. Your name should describe what an element does as precisely as practically possible.
+It also helps to avoid ambiguity and naming collisions within and across plugins. Ensure that names clearly and precisely describe the purpose of an element to make its functionality immediately apparent.
 
 For example, we prefer `functionalUnit` to `funcUnit`, `fUnit`, or any other abbreviation.