I'm thinking about when is the perfect moment to run a SAST review but I am not sure. For me the best moment is before merging my branch to master (on the pull request), due to, you can fix it before putting your code on production. However, imagine, there are two or more branches without any vulnerability (you run your SAST review before merging these branches), is it possible new vulnerabilities appear on the code if you merge these branches without vulnerabilities into master? I mean the combination of different code without vulnerabilities can make you code vulnerable? if yes, could you give an example? does it make sense to run another SAST review on master (after merging any branch)?
Related
I would appreciate any help to find a way to make it impossible for any single person to make changes to the master branch of a Github repository without having that change reviewed by another person. Using the usual branch protection rules, I have been unable to see how I can prevent the following scenario:
Person A makes a legitimate PR.
Person B inserts a malicious change to the PR. Then reviews the PR with their own malicious change, and subsequently merges to master.
I have considered raising the number of required reviews from 1->2, but I would prefer another solution.
Any help is greatly appreciated, thank you.
I have a project, based on buildroot, which is composed of two repos:
Buildroot root, let's say project A
Our packages, project B
We host a Gitlab server, and I'd like to set up a CI/CD job for the compilation.
The process I want to set up is as follow:
If a merge request (MR) appears on A/B -> trigger a pipeline.
If two MRs appears on both repos, referring the same issue, in a 15 minutes interval (this timer is to give some time to the developer to create all his MRs for his issue) -> trigger a single pipeline visible for both of the MRs.
The last point is where I struggle. Basically, what I want is to have one unique pipeline for one issue, so that if both repos have a MR for this particular issue, my pipeline would checkout on the correct branch for A and B and then launch the compilation for it.
I know I can trigger a pipeline on repo A from B, but I can't figure out how to ensure a unique pipeline will be launched if two MRs are created. Because right now, from what l can see, each MR would create it's pipeline and I'll end up with two compilations...
I've thought about using buildbot with Gitlab, but I'd prefer to stay on Gitlab only, because it's easier to maintain, than having many different tool for this.
Does anyone have ever faced this kind of problem on Gitlab and/or have a clue on how to deal with it ?
Thanks in advance!
Edit
I've come across this page which appears to be the exact solution to my problem, and unfortunately that seems not to be on the roadmap.
I'll dig into the proposition of having a meta project above A and B, because it would allow me to keep everything with Gitlab-CI, even if it means creating this project and dealing with a special process...
Answering my own question.
I've been trying to build up a setup with buildbot for several days, but as I said I really don't wanna add another tool to manage (my team isn't ready for this, and buildbot does too many things that we don't need for now).
I've come into this comment which made me chose the following approach.
Gitlab.example.com
A B *NEW Project 'C' only for CI/CD*
------\/------ ----------------\/--------------
- Trigger C with Key for the issue X, - Fetch/clone A and B for issue X
unless one already exists for issue X - Prepare the sources
- Wait for C to finish - Compile
- Report C's status (with URL to the
corresponding Pipeline)
This setup is the best I can get for a Gitlab-only solution.
If someone's interested in the code I used, tell me and I'll post sample.
I have 2 JIRA tickets and changes done affect different files.
So if I send a merge request to one person to review, can I add both the commits in one merge request (but the commit history should be shown for both of the tickets).
We can have this in a way by adding the two JIRA ticket numbers in the commit message.
In this way both the tickets will be updated with this commit which includes fix for both the tickets.
And the merge request will be one.
I am not sure if this is a good way but maybe this will be good if you alone are working in that module and no one else does any changes to the files under change
I have an issue on gitlab, #1. This issue when it was created it contained two tasks.
Is there a way to mention/reference/close one of the two tasks in a git commit ?
Not yet, but at least you can define tasks in an issue now.
This comes with GitLab 15.3 (Aug. 2022)
Create tasks in issues
Tasks provide a robust way to refine an issue into smaller, discrete work units.
Previously in GitLab, you could break down an issue into smaller parts using markdown checklists within the description.
However, these checklist items could not be easily assigned, labeled, or managed anywhere outside of the description field.
You can now create tasks within issues from the Child Items widget.
Then, you can open the task directly within the issue to quickly update the title, set the weight, or add a description.
Tasks break down work within projects for GitLab Free and increase the planning hierarchy for our GitLab Premium customers to three levels (epic, issue, and task).
In our next iteration, you will be able to add labels, milestones, and iterations to each task.
Tasks represent our first step toward evolving issues, epics, incidents, requirements, and test cases to work items.
If you have feedback or suggestions about tasks, please comment on this issue.
See Documentation and Epic.
We are investigating a workflow in Perforce where we create a new temporary branch for every feature project. When projects are stable, they're integrated back into our main branch. Down the line, we would like to remove old project branches from the repository. However I believe this will also delete all revision history for the files modified in the branch. Is it possible to integrate the revision history from the project branches into the main branch?
One solution that I've considered is to manually integrate each individual checkin when merging code back into the main branch. This does not seem like the right approach.
The revision histories as stored against the branch they are applied to, so it is not possible to merge from one to the other. Your idea about integrating each changelist from the project branch will work, but is also a pain as you have pointed out.
I've made extensive use of branching over the years and I can't remember a case where we wished we'd had the branch revision history in the main line or even looked at the branch revision history after the branch was merged back into the main line.
You'll have the revision histories available (though not directly) for a while after a merge and (ideally) anything you check in to the main development branch should pass all the unit tests so the chances of it breaking should be minimised.
First of all, why do you want to remove the branches from the repository? Are you noticing having multiple branches to affecting performance (or expecting it to)? For each 'temporary' branch are you taking an entire copy of the main line? Also why do you consider these branches 'temporary', I would argue if they are for a feature then they are not and should be preserved.
A few articles to read:
- P4 KB Sparse Branching
- P4 Blog: Perforce Anti-Patterns Over-Branching
I believe, without knowing more information, that you could: use sparse branching, make these 'temporary' branches permanent, and if you really have a need for a temporary branch create a private working branch for each of your developers.