ci(trivy): fix scan failures due to TOOMANYREQUESTS DB error

[aldousalvarez]

Commit to be reviewed

---

ci(trivy): fix scan failures due to TOOMANYREQUESTS DB error

Primary Changes
----------------
1. Updated the ci.yaml to make the trivy scan 
   run only on the weekends

Fixes #3652

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[outSH]

Looks fine, but I'd rather have a separate "weekly" job triggered by cron (https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule), it will be easier to see and add new weekly jobs, and it doesn't convolute our CI job with more prerequisites. @petermetz any thoughts?

[petermetz]

Looks fine, but I'd rather have a separate "weekly" job triggered by cron (https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule), it will be easier to see and add new weekly jobs, and it doesn't convolute our CI job with more prerequisites. @petermetz any thoughts?

@outSH Can't say I disagree. I would love to remove the code from the diff that calculates the day of the week.

[petermetz]

@aldousalvarez Looks good in general, but please incorporate the change request from @outSH

[aldousalvarez]

Hello @petermetz and @outSH, done with the requested changes and incorporated it. Re-requested for review. Thank you

[petermetz]

LGTM

[petermetz]

@aldousalvarez On second thought, are you sure you didn't just disable running ci.yaml in pull requests completely? I noticed after a rebase that the jobs are not running at all. Could be a coincidence but it could also be that the new scheduling overrides the other declarations that make it so that ci.yaml should run for each PR? Could you please double check the github docs?

[aldousalvarez]

@petermetz Okay, I will take a look into this. I think the scheduled workflow will only run on the default branch so I will test it on my fork.

[petermetz]

@petermetz Okay, I will take a look into this. I think the scheduled workflow will only run on the default branch so I will test it on my fork.

@aldousalvarez Thank you! As I'm typing this, the checks on this PR are still stuck in 'waiting for status to be reported' so it is looking more and more like the schedule is having some sort of negative side effect here (I'd love to be wrong here though)

build-dev Expected — Waiting for status to be reported
Required
cactus-common Expected — Waiting for status to be reported
Required
cactus-core Expected — Waiting for status to be reported
Required
cactus-core-api Expected — Waiting for status to be reported
Required
yarn_codegen Expected — Waiting for status to be reported
Required
yarn_custom_checks Expected — Waiting for status to be reported
Required
yarn_lint Expected — Waiting for status to be reported
Required
yarn_tools_validate_bundle_names Expected — Waiting for status to be reported
Required

[aldousalvarez]

@petermetz It is now working. What I did was I cleaned the code and added the changes again, I think it is some lint error or whitespaces that is why it did not read the condition from before.

[petermetz]

@aldousalvarez Got it, thank you!