Optimize CI/CD workflows by excluding redundant CI runs on direct master pushes

[origranot]

Description

Currently, our development process triggers both Continuous Integration (CI) and Deployment (CD) workflows when new code is pushed to the master branch.
While this is crucial for maintaining code quality and ensuring reliable deployment, it has been observed that running the CI workflow for direct pushes to the master branch may be redundant.
This is especially true if the code has already passed through the CI checks in a separate development or feature branch before merging.

Screenshots

No response

Additional information

Outcome:

• Optimize the CI/CD process by configuring the pipeline to intelligently skip the CI workflow for direct pushes to the master branch, where it's confirmed that the code has already passed CI checks.
• Ensure that this optimization does not compromise the integrity and reliability of the code in the master branch.
• Maintain or improve the current deployment speed and resource efficiency.

[godwintrav]

Hi I can work on this @origranot

[origranot]

Hi I can work on this @origranot

Yea! go for it champ!

[godwintrav]

Thank you I'm on it

[godwintrav]

Hi @origranot I have a proposed solution but there are tradeoffs. so I would like to know which you would think is better since you are an owner of the repository.

so we can skip the CI workflow after it has been run in development or feature branches by either labeling the PR with ci-skip or updating the PR metadata and appending [ci skip] either to commit message or anyother metadata. I personally will recommend using labels if we decide to automate tagging those PR's.

Now with labels we can we can enforce every reviewer adds the ci-skip label to that PR before merging if the workflow ran successfully or we also automate that workflow by calling the github API and adding the label after the CI workflow has been run, but this way requires a GITHUB TOKEN for PR's from the repository and a GITHUB PERSONAL ACCESS TOKEN for PR's from a forked repository available in the CI environment.

The other option which is updating the PR commit message or metadata is also good if it is enforced that it is added by reviewers or contributors after the CI workflow has been run successfully.

With any of those two options I can now add a conditional statement to check if the label or commit message has the ci-skip and then skip the workflow in that instance.

so please let me know which you think is best and can be done or enforced from your side and then I can start working on it immediately.

Thanks @origranot I hope to hear from you soon

[godwintrav]

@origranot I am waiting to hear from you?

[origranot]

Hey @godwintrav, thanks for the detailed breakdown!

After giving it some thought, I believe we still need to run the CI after the push to master to ensure the code works properly before releasing. While skipping CI on master pushes might seem appealing for efficiency, we can't compromise on the final validation step before release. What we really want to achieve is to avoid redundant CI runs for changes that have already passed CI checks in development/feature branches.

Perhaps a better approach would be to keep the CI workflow on master but make it conditional based on whether the push is part of a release process. For example, we could skip the CI for regular pushes but run it for tagged releases or specific release-related commits. This way, we maintain validation before release but still streamline the workflow.

What do you think? Would that strike the right balance?

Thanks again for working on this!

[godwintrav]

yes it will but there will need to be a way to differentiate between regular pushes to master and release related pushes to master perharps adding a tag with release in the commit would be helpful to make the conditional statement more straightforward to create. Also we can use the application versoning. I would like to know when creating releases for the app is the version in package.json bumped? if it is then I can use that instead of tagging it.

What do you think? What would be the best way to differentiate what commit is regular and what commit is release related?
Thank you for your response hoping to hear from you regarding this current question @origranot

[godwintrav]

HI @origranot what do you think about my last suggested solution?