-
Notifications
You must be signed in to change notification settings - Fork 20
5.5 Actions
The actions section allows unique functionalities that may significantly boost productivity when working with SPFx projects.
It is possible to:
Uses CLI for Microsoft 365 to create a .md
report with upgrade guidance to the latest supported SPFx version by the extension. The upgrade guidance provides optional as well as required steps a user needs to take manually in order to upgrade the project. At the end of the guidance file, the user may find a summary of the steps in a single script and a couple of manual steps that need to be taken
For more information check out the spfx project upgrade command in the CLI for Microsoft 365 docs.
Creates a validation .md report against the currently used SPFx version in the project. The action will automatically detect the SPFx version used and will validate if the project is properly set up.
For more information check out the spfx project doctor in the CLI for Microsoft 365 docs.
The action will rename your project in the following places:
- package.json,
- .yo-rc.json,
- package-solution.json,
- deploy-azure-storage.json
- README.md.
When specified it will also generate a new solution ID.
For more information check out the spfx project rename in the CLI for Microsoft 365 docs.
The action will Grant all API permissions specified in the package-solution.json of the current project. This is especially helpful if you just want to debug your SPFx solution using Workbench. No longer do you need to bundle, package, and deploy the project to then go to the SharePoint admin portal and consent to the permissions. All of that is now done with just a single click
For more information check out the spfx project permissions grant in the CLI for Microsoft 365 docs.
This action will only work when the user is logged in to tenant and the sppkg file is present. The action will deploy the project to the selected (tenant or site) app catalog.
For more information check out the spo app add and spo app deploy in the CLI for Microsoft 365 docs.
Allows scaffolding a new SPFx project as a new component of the currently opened project. The action under the hood uses the same SharePoint Yeoman generator to scaffold a new project and this feature is an abstraction UI layer. The extension will ask for the same information when adding a new component as the SPFx Yeoman generator. After that Viva Connections Toolkit will extend the currently opened project with a new component.
This action will allow you to generate yaml GitHub workflow that uses CLI for Microsoft 365 GitHub actions to bundle, package, and deploy your project to an app catalog on every code push.
Currently, this action only supports GitHub workflows as it generates a pipeline that uses CLI for Microsoft 365 GitHub actions. In the future, this feature will be extended to support other platforms like Azure DevOps.
Viva Connection Toolkit extends VS Code with additional UI to present you with a scaffolding form that will allow you to create a CI/CD Workflow in 3 easy steps. It's important to know that many fields are already prefield and it is possible to hit create without changing any value to get a basic and default YAML workflow file.
name: Deploy Solution test-solution
on:
push:
branches:
- main
workflow_dispatch: null
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/[email protected]
- name: Use Node.js 16.x
uses: actions/[email protected]
with:
node-version: 16.x
- name: Run npm ci
run: npm ci
- name: Bundle & Package
run: |
gulp bundle --ship
gulp package-solution --ship
- name: CLI for Microsoft 365 Login
uses: pnp/[email protected]
with:
CERTIFICATE_ENCODED: ${{ secrets.CERTIFICATE_ENCODED }}
CERTIFICATE_PASSWORD: ${{ secrets.CERTIFICATE_PASSWORD }}
TENANT: ${{ secrets.TENANT_ID }}
- name: CLI for Microsoft 365 Deploy App
uses: pnp/[email protected]
with:
APP_FILE_PATH: sharepoint/solution/test-solution.sppkg
SKIP_FEATURE_DEPLOYMENT: true
OVERWRITE: true
Scaffolding form
1 step
In the first section of the form you may provide general information about your workflow like what will be its name, or what is the name of the branch that every push will trigger the flow to run. It is also possible to allow you to run the workflow manually using the GitHub UI
2 step
In the second step, you will need to decide how your flow will authenticate to your tenant. It is possible to pick between user and application login method
for application
, the following yaml will be generated for this step (this is the default option).
- name: CLI for Microsoft 365 Login
uses: pnp/[email protected]
with:
CERTIFICATE_ENCODED: ${{ secrets.CERTIFICATE_ENCODED }}
CERTIFICATE_PASSWORD: ${{ secrets.CERTIFICATE_PASSWORD }}
APP_ID: ${{ secrets.APP_ID }}
TENANT: ${{ secrets.TENANT_ID }}
It is also possible to generate a certificate and create a new Entra ID app registration directly within the form for your workflow. Simply check the additional checkbox and provide a password for your certificate and the name for your new app registration. Submitting the form will also create the file and the app and at the end, it will give you the generated values so that you may copy them to the secrets that are required to be created in GitHub repo for this authentication method.
for user
, the following yaml will be generated for this step
- name: CLI for Microsoft 365 Login
uses: pnp/[email protected]
with:
ADMIN_USERNAME: ${{ secrets.ADMIN_USERNAME }}
ADMIN_PASSWORD: ${{ secrets.ADMIN_PASSWORD }}
3 step
Here we may specify if we will deploy the app to tenant or site-level app catalog. When the site type is selected then an additional select field will be presented to specify the site app catalog url. For the site type the following yaml will be added to the last step
SCOPE: sitecollection
SITE_COLLECTION_URL: https://sharepoint.tenant.com/appcatalog
This action only generates the workflow yaml file. It does not do any additional setting on GitHub. Depending on which login method you select additional steps are needed.
Depending on which authentication method was selected in GitHub repo settings, you will need to create the following secrets:
For the application
login method you will need to create the following secrets in GitHub repo settings:
-
APP_ID
- client id of the registered AAD application -
CERTIFICATE_ENCODED
- application's encoded certificate -
CERTIFICATE_PASSWORD
- certificate password. This applies only if the certificate is encoded which is the recommended approach -
TENANT
- Tenant ID
This use case is perfect in a production context as it does not create any dependencies on an account.
For the user
login method you will need to create the following secrets in GitHub repo settings:
-
ADMIN_USERNAME
- username -
ADMIN_PASSWORD
- password
This use case is perfect for testing. It will not work if the specified account uses MFA.
Check it out in action 👇
For more information check out the spfx project github workflow add and how to automate your CI/CD workflow using CLI for Microsoft 365 GitHub Actions in the CLI for Microsoft 365 docs.
Viva Connections Toolkit supports a couple of sample galleries that may be used to scaffold a new SPFx project. You may use the sample gallery to kick off a new solution or for inspiration for your current one.
Check out the other resources we have in the what you may find on the wiki section.