https://netsuiteprofessionals.com logo
Join Slack
Powered by
till now we only used the SuiteCloud CLI for Node...
# sdf
s
till now we only used the SuiteCloud CLI for Node.js to upload files via this command
Copy code
suitecloud file:upload -i ` the problem with this is it would skip our central version control Github CI/CD  we would like to implement all new changes submitted to GitHub and then kick off a GitHub action is this something doable?
e
Yes. 
suitecloud
is an npm package like any other that you can install in your GH Actions Workflow. I wrote a free course on doing so, though I don't use 
file:upload
specifically.
c
We also use npm with suitecloud here w/ bitbucket works well
s
this course was great helped me understand THE SDF much better
❤️ 1
Im currently getting a npm error
Copy code
npm ERR! The `npm ci` command can only install with an existing package-lock.json or
npm ERR! npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or
npm ERR! later to generate a package-lock.json file, then try again.
e
It's telling you to run 
npm install
locally, which will generate a 
package-lock.json
file, and then commit the 
package-lock.json
file to your repo. Then 
npm ci
will use that to pull in dependencies with fixed versions.
Any time you want to update the versions specified in 
package-lock
, you just run another 
npm install
or 
npm update
locally and commit the changes to 
package-lock
s
I tired that already didtn seem to work
do i need to check the node_modules into git ?
e
Nope, you don't want to do that
Hard to troubleshoot from here, but as long as 
package-lock.json
exists in the repo on the branch where you are trying to run 
npm ci
and npm is greater than version 5 (current is 10), you shouldn't see that error.
s
this is going to sound very typical works on my dev pc
Copy code
npm ci --acceptsuitecloudsdklicense
a
@erictgrubaugh In your experience, can CI and CD be done with a SOX-compliant company (aka Public Company?) where the developers cannot deploy code to Production?
e
Yes. I work for a public, SOX-compliant company now where we (the devs) only have read-only access to Production. We designed a non-UI Role specifically for deployments that our CI/CD pipeline uses. Works well for us.
We use CircleCI, so we made an Employee record for CircleCI and gave it the necessary tokens and roles. None of us can log in to that account directly.
a
So the Employee X(no developer) clicks merge somewhere and that merges the code to master a do the deployment?
e
We essentially do release trains, deploying every Tuesday. On Monday mornings before working hours, CircleCI automatically tags the tip of 
main
as a Release Candidate and deploys that to a sandbox. We then have all of Monday and Tuesday to validate the Release Candidate in said sandbox. Tuesday mornings before working hours, CircleCI automatically kicks of the Production build (lint, validate, unit test) from the most recent Release Candidate tag; assuming all of that passes, the CircleCI Workflow holds for manual approval. Once our Change Control doc is signed and approved, our on-call engineer logs in to CircleCI and approves the hold, and deployment proceeds automatically from there.
👍 1
Any features merged after the Release Candidate tags get created will catch the next train the following week
👍 1
a
I need to do some testing to check if I can implement that approach in my team, sounds very good 👍 …
e
Has its pros and cons, like all things
s
I'm a little confused how would I decide if code is pushed to sandbox vs production?
e
You can use the 
suitecloud account:setup
or 
suitecloud account:savetoken
command to select the account. There's a ton of different ways you might approach that in a CICD environment, so it's hard to give specifics without a ton of context
s
i have both auth token inside my local machine
how can i decide which account this command will
Copy code
suitecloud project:deploy
e
suitecloud account:setup
s
every time i want to switch back and forth i would need to run that ?
e
Yes. How often do you switch accounts?
s
not often rant still doesn't sit well with developer brain , design practice should not be to change the default but have a way to set flag , should have the flag /rant
Copy code
---account
e
That's valid. I aliased the command to 
scas
a long time ago and don't even think about it anymore; it's muscle memory for me to 
scas; scd
to select an account and deploy
but obviously that doesn't translate well to anyone else 🙂
s
nice idea
e
My suitescript relevant bash aliases, for the curious:
Copy code
# suitecloud aliases
alias sc='suitecloud'
alias scd='sc project:deploy'
alias scv='sc project:validate --server'
alias scas='sc account:setup'
s
this is mine that i stole from you
Copy code
function createNS() {
suitecloud project:create -i
cd $1
suitecloud account:setup
suitecloud file:import -i
suitecloud object:import -i
suitecloud project:adddependencies
suitecloud project:validate
}
👍 1
e
I rarely create projects these days, but yes that's a good one as well
s
it just goes into a repo I have on my GitHub repo
❤️ 1
46 Views
Open in Slack
PreviousNext
Powered by