you are going to need a yaml file in your repo und...
# dev-ops
p
you are going to need a yaml file in your repo under (.github/workflows/[action-name].yaml) https://docs.github.com/en/actions/using-workflows and then you need to setup the order of your workflow ex. when there is a push on a certain branch execute the action. for this you will need account ids, token id's, token secrets, ... (create a new integration record + manage the access tokens) in the steps (yaml file) is needed: -install java -install node -install suitecloud -create the sdf account -run parameters ... run deploy
c
Hey @Philip Denys . Thanks for sharing this. This is very helpful. I’m struggling to build yaml file for SDF deployment. Any reference on creating yaml file with SDF commands? I tried all the ways but when running workflow it is throwing errors.
e
I've been learning GitHub Actions myself recently; will be publishing an article soon about how I set it up
👌 1
❤️ 1
c
Hey @erictgrubaugh, thanks for the update. I took your course on SDF on salto website . It was awesome and well organised. I’m looking forward to seeing more content like that.
❤️ 1
1
j
@erictgrubaugh holler if you want to talk. We use Azure DevOps pipelines- just another automation tool (shares a lot of features with Github Actions). I generally use a trunk based approach for misc client work. I want to 1. Lint my javascript (wish we had tests to execute, but we don’t) 2. Validate that my SDF package can be deployed to both this customer’s sandbox and prod accounts 3. Package my artifacts up so that my release pipeline can act upon these vetted artifacts
Copy code
name: $(SourceBranchName)-$(Build.BuildId)

resources:
- repo: self

pool:
  vmImage: 'ubuntu-latest'

trigger:
  branches:
    include:
    - main

variables:
  nodeVersion: '16.x'
  dotNetVersion: '7.0.x'


stages:
- stage: LintAndScanForSecrets
  displayName: Lint and Scan for Secrets
  dependsOn: [] # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    steps:

    - task: NodeTool@0
      displayName: 'Install NodeJS'
      inputs:
        versionSpec: $(nodeVersion)

    - bash: |
        yarn install
        yarn run lint
      workingDirectory: '$(System.DefaultWorkingDirectory)'
      displayName: 'Lint Netsuite Account Customization Packages'

    - task: MicrosoftSecurityDevOps@1
      displayName: 'Secrets scanning with Microsoft Security DevOps'
      inputs:
        categories: 'secrets'
        break: true

- stage: FooSandboxValidation
  displayName: Foo Sandbox Validation
  dependsOn: []
  variables:
  - group: Foo Netsuite (Sandbox)
  jobs:
  - job: 
    steps:

    - task: NodeTool@0
      displayName: 'Install NodeJS'
      inputs:
        versionSpec: $(nodeVersion)

    - task: JavaToolInstaller@0
      inputs:
        versionSpec: '17'
        jdkArchitectureOption: 'x64'
        jdkSourceOption: 'PreInstalled'

    - bash: npm install -g --acceptSuiteCloudSDKLicense @oracle/suitecloud-cli@1.6.2
      displayName: 'Install SuiteCloud CLI'

    - bash: suitecloud account:savetoken --account "$(netsuiteAccount)" --authid "$(name)" --tokenid "$(tokenId)" --tokensecret "$(tokenSecret)" || true
      displayName: "Sandbox Netsuite account:savetoken"
      workingDirectory: '$(System.DefaultWorkingDirectory)/Netsuite/AccountCustomization/Compass'

    - bash: suitecloud project:validate --server
      displayName: "Sandbox Netsuite project:validate"
      workingDirectory: '$(System.DefaultWorkingDirectory)/Netsuite/AccountCustomization/Foo'

- stage: FooProductionValidation
  displayName: Foo Production Validation
  dependsOn: []
  variables:
  - group: Foo Netsuite (Production)
  jobs:
  - job:
    steps:

    - task: NodeTool@0
      displayName: 'Install NodeJS'
      inputs:
        versionSpec: $(nodeVersion)

    - task: JavaToolInstaller@0
      inputs:
        versionSpec: '17'
        jdkArchitectureOption: 'x64'
        jdkSourceOption: 'PreInstalled'

    - bash: npm install -g --acceptSuiteCloudSDKLicense @oracle/suitecloud-cli@1.6.2
      displayName: 'Install Suitecloud CLI'

    - bash: suitecloud account:savetoken --account "$(netsuiteAccount)" --authid "$(name)" --tokenid "$(tokenId)" --tokensecret "$(tokenSecret)" || true
      displayName: "Sandbox Netsuite account:savetoken"
      workingDirectory: '$(System.DefaultWorkingDirectory)/Netsuite/AccountCustomization/Foo'

    - bash: suitecloud project:validate --server
      displayName: "Sandbox Netsuite project:validate"
      workingDirectory: '$(System.DefaultWorkingDirectory)/Netsuite/AccountCustomization/Foo'

- stage: PackageArtifacts
  displayName: Package Artifacts
  dependsOn:
    - LintAndScanForSecrets
    - FooSandboxValidation
    - FooProductionValidation
  condition:  and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
  jobs:
  - job:
    steps:

    - publish: '$(System.DefaultWorkingDirectory)/Netsuite/AccountCustomization'
      artifact: FooSDFPackge
❤️ 1
Here’s this little repo structure
c
Thanks @Joel Musheno for the information. I’m working on something similar to this using GitHub actions. I just curious to know If above provided yaml file will work with the git hub actions workflow to integrate with NetSuite account using required tokens and configurations.
j
@Charan there’s a ‘secrets’ mechanism built into ADO where you can parameterize secrets in environment variables (e.g.
$tokenId
$tokenSecret
) It will, most likely, not work with github actions. Github has it’s library of ‘actions’ (https://github.com/marketplace?type=actions) and Azure DevOps has it’s library of ‘tasks’ (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/?view=azure-pipelines&viewFallbackFrom=azure-devops) They perform similar actions, but the syntax differences is something you’ll have to research. e.g.
-bash:
executes a shell script/inline command in ADO The github equivalent looks to be
Copy code
- shell: bash
        run: |
          expr 1 + 1 > output.log
e
Thanks for the nudge! My introduction to CI/CD was posted here, and Part 2 which actually goes into using GH Actions is being reviewed and published soon(tm).
The YAML for GH Actions will look strikingly similar
The context-less repo with my config file is here
It runs unit tests, then validates, then deploys leveraging environment secrets for the Token values and an environment variable for the target Account ID
❤️ 1
Direct link to config file
❤️ 1
Please do not just drop this in to a Production project/repo 😄
👍 1
c
Thanks @erictgrubaugh . This is very helpful 🫡
1