| #!/bin/bash | |
| SVN_LINK="svn://localhost/ultrastardx" | |
| PROJECT_DIR="script_test2" | |
| GITLAB_REPO="just_testing_grp/advanced/bash_script02" | |
| echo 'SVN to Gitlab migration tool' | |
| # Modify the SVN (source) link! | |
| svn info "${SVN_LINK}" |
| Single Ticket vs. Multiple Tickets: Given the number of findings (around 200), it's more manageable to create multiple tickets in JIRA. One ticket for all findings would be overwhelming and difficult to track. Instead, group findings by type, severity, or component, and create a ticket for each group. | |
| Categorize and Group Findings: Before creating tickets, categorize the findings. Group them into buckets such as 'Critical Bugs', 'Performance Issues', 'Security Vulnerabilities', etc. This will help in creating focused tickets that can be tackled by developers with the right expertise. | |
| Create JIRA Tickets: For each group of findings, create a JIRA ticket. The ticket should include all necessary information about the findings, such as the file names, line numbers, and a brief description of the issue and suggested fix if available. | |
| Divide and Conquer: | |
| Assign tickets based on developer expertise, ensuring the most complex issues are handled by the most experienced developers. | |
| If possible, allocate sim |
| --- | |
| Title: Implementation of Jenkins Pipeline for Build and Release Process | |
| Description: | |
| #The current Jenkins pipeline process is crafted to streamline the build and release of software artifacts, emphasizing clarity and minimalism in each step. | |
| #Currently only the Build Stage is implemented. | |
| #The process encompasses the following stages: | |
| Source Stage: | |
| Developers commit code on Trunk. |
| 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. |
| Memory Safety: | |
| Avoid buffer overflows and underflows. | |
| Prevent memory leaks. | |
| Ensure proper pointer arithmetic. | |
| Input Validation: | |
| Validate user inputs to prevent injection attacks. | |
| Sanitize and validate data from external sources. | |
| Error Handling: |
Quick notes on setting up a lightweight SVN server that is accessible via http (WebDav) and the svn custom protocol (svn://).
credits to :