Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sandbox:update fails to ever set stop-schedule or start-schedule #577

Open
lawrencewalters opened this issue Jan 27, 2025 · 0 comments
Open
Labels
bug Something isn't working

Comments

@lawrencewalters
Copy link

sfcc-ci Version

2.12.0

NodeJS Version

v10.24.1

sfcc-ci Path

/home/xxxxxxx/.nvm/versions/node/v10.24.1/bin/sfcc-ci

Host OS Details

Linux USHQL835 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Description

When making any request to sandbox:update with a stop-scheduler or start-scheduler request, the request always fails, and at the same time, sets auto-scheduled to false (see log output, where a --stop-scheduler request is made, and eventually the PATCH request is made, and the body simply has autoScheduled: false.

It turns out this an issue with parameter order in cli.js

        if (scheduleOk) {
            require('./lib/sandbox').cli.update(spec, ttl, autoScheduled, false, startScheduler, stopScheduler);
        }

But the function signature for update is:

   /**
     * Update a sandbox.
     *
     * @param {String} spec specification of the sandbox to update
     * @param {Number} ttl number of hours, the sandbox TTL will be prolonged
     * @param {Boolean} autoScheduled sets the sandbox as auto scheduled
     * @param {String} startScheduler start schedule for the sandbox
     * @param {String} stopScheduler stop schedule for the sandbox
     * @param {Boolean} asJson optional flag to force output in json, false by default
     */
    update : function(spec, ttl, autoScheduled, startScheduler, stopScheduler, asJson) {

so the hardcoded false parameter is throwing off the scheduler parameters, and thus a stopScheduler is always determined to be null based on the update function parameter validation.

Relevant log output

$ sfcc-ci sandbox:update -s xxxxxxxx --stop-scheduler '{"weekdays":["MONDAY","TUESDAY","WEDNESDAY","THURSDAY","FRIDAY"],"time":"23:00:00Z"}' -D
...

REQUEST { auth:
   { bearer:
      '....' },
  json: true,
  uri:
   'https://admin.dx.commercecloud.salesforce.com/api/v1/sandboxes/xxxxxxxxxxx',
  method: 'PATCH',
  body: { autoScheduled: false },
  callback: [Function] }

....
@lawrencewalters lawrencewalters added the bug Something isn't working label Jan 27, 2025
lawrencewalters added a commit to lawrencewalters/sfcc-ci that referenced this issue Jan 27, 2025
the sandbox:update logic calls update() with the wrong order of parameters so that stopScheduler is always null... this corrects that
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant