Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save mauricioduarte01/fba0de12457c9c3167fa0694c6a9b566 to your computer and use it in GitHub Desktop.

Select an option

Save mauricioduarte01/fba0de12457c9c3167fa0694c6a9b566 to your computer and use it in GitHub Desktop.
nada
https://app.eraser.io/workspace/zXtfgL0Wih22fXbAK8cm
In a Jenkins pipeline, the cleanWs() step is used to clean up the workspace, deleting directories and files that may have been left from previous builds. Whether you should use it at the beginning or the end of a pipeline (or both) can depend on your specific needs and workflow.
Here are the common practices:
At the Beginning: Using cleanWs() at the start of a pipeline ensures that you have a clean state before you begin your build process. This is helpful to prevent any conflicts or inconsistencies that may arise from residual files from a previous build.
At the End: Placing cleanWs() at the end of a pipeline is useful for housekeeping purposes, ensuring that no unnecessary files are left on the build agent after the job is completed. This helps to conserve disk space on the agent.
Both: Using cleanWs() both at the beginning and the end can be considered a more rigorous approach, where you ensure a clean workspace before you start and also clean up after yourself when you're done.
It's also important to consider the following:
If you have multiple builds running on the same agent in parallel, you should be careful with the cleanup process so that one build does not delete the workspace of another.
If your builds are incremental and rely on artifacts from previous builds, using cleanWs() might not be appropriate as it would delete those needed artifacts.
Some teams prefer to clean up at the beginning to minimize the time spent in the "post" section of the pipeline, which is generally used for steps like sending notifications, collecting artifacts, and other end-of-pipeline tasks.
It's always good to tailor the usage of cleanWs() to the specific needs of your CI/CD process.
@mauricioduarte01
Copy link
Author

The Unix philosophy emphasizes designing small, modular utilities that do one thing and do it well, rather than creating complex, multi-functional programs. This approach favors simplicity and the ability to chain programs together to perform complex tasks. Each program receives input, processes it, and produces output in a straightforward manner, which makes debugging and adaptation easier.

The KISS principle, which stands for "Keep It Simple, Stupid," advocates for simplicity in design. It suggests that systems work best when they are kept simple rather than made complicated; simplicity should be a key goal in design, and unnecessary complexity should be avoided.

Synthesizing both, the core idea is that simplicity leads to greater efficiency, maintainability, and functionality in system design. By focusing on simple, single-purpose tools that perform their function well, and by avoiding unnecessary complexities, you create a system that is more robust, easier to understand, and easier to manage. Both philosophies celebrate the elegance and efficiency found in simplicity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment