I want to test my pipeline and not have a commit everytime i make a change. Is there a way to prevent this, in order not to have a bunch of unnecessary commits on my develop branch?
You can use git commit --amend to push the commit into the previous one, this will trigger the pipeline to run with the new changes without "bloating" your git history with many commits.
Here is a tutorial to help you out: https://www.atlassian.com/git/tutorials/rewriting-history
Related
As in the title: there's always the statement The source branch is 1 commit behind the target branch. How is it even possible: both master and develop branches are up to date, no one made any modifications in the meantime, and the merge request gets created via GUI operating on the most up to date version of the repository, isn't it?
I read GitLab documentation saying that it could be the merge commit counted as this 1 commit behind, so I changed my project settings to:
It didn't change anything however: there's still the same message:
So far, I make a rebase in the following way:
git checkout master
git pull
git checkout develop
git merge master
git push
to line up the branches, but I'd like to save myself these few additional steps. Is it possible to achieve?
I use GitLab on-premise and need to change the contents of a file automatically when I push into my feature branch so when tests run and code is executed, one of the files called from within the repo itself has modified content. When I merge that branch into master, I need to undo that change.
It's not enough to override the file contents just when the test runs, because of how the application works. It will end up pulling the repo from GitLab on it's own and execute one of the files contained within.
I have been looking into hooks a little bit, but I can't find any references or examples on how to accomplish something like this.
Currently I am changing the file manually so my CI tests run accurately. If the tests then pass, I can manually change the file back and skip the CI tests on the final push, and then merge into master.
There's not really a default way to automatically change, commit and push back into Gitlab from a pipeline, as the pipeline does not have authorization to write into the repo.
However, you can provide a "Personal Access Token" (PAT) for one of Gitlab's users (or even a special service-account created for that purpose) - either commit that to your repo (which is quite unsafe) or provide it through the "CI/CD Variables" setting from within Gitlab.
Your pipeline will then need to do something like:
# change file.txt
# add the remote with credentials authorized to commit; do not fail if the remote already exists
git remote remove pushorigin || true
git remote add pushorigin https://commituser:${PAT}#gitlab.local/path/to/project.git
# add and commit the file
git add file.txt
git commit -m "Commit Message"
# move the remote's branch tip:
git push pushorigin "HEAD:${CI_COMMIT_REF_NAME}"
I don't have a clue how to revert that automatically when/before finally merging the branch. Don't you mind those testing commits being merged back into main, possibly creating conflicts on those files?
I guess overall, the application should be modified to better support testing on those branches.
I need to set up a pipeline for a branch that will do the following,
On push, it will trigger a pipeline (which happens as per GitLab)
1st Job to trigger a build (.net5) for the branch (new code pushed to the branch). If the build succeeds, it will begin the next job. However, I am to trigger build (MSBuild) on the runner location check out when the pipeline runs. But is there any way to directly run a build on the branch?
If the above build fails, the push should be reverted on a branch. I applied git revert and reset commands, but it only gets used to the build location of the runner. I need to revert commit at the branch level.
When GitLab starts a pipeline, it is a "detached HEAD" which basically means it creates a temporary branch that points to your specific commit. It does this because there might be a commit after it which the current build doesn't know about.
To get out of the detached head, you need to switch to the branch directly.
git checkout branch-name
To get the branch name, you find an appropriate predefined variable which works for your.
Once you have that, you need to get the latest version so you can revert. I usually needed the reset here to make things work.
git reset --hard
git pull
From there, you can revert. Now, the CI process doesn't have write permissions, so you need to have a GitLab access token with write permissions, which means you have to set up a new origin or parent.
git remote add changes https://oauth2:$PUSH_GITLAB_TOKEN#gitlab.com/group-name/project-1
git push -f changes branch-name
Now... that said, this is probably not what you want to do. Since you said you were new to CI, I'm going to say I'm 99.99999% sure you don't want to go down this path because it only leaves to heartache and frustration.
The reason is the branch may have a second or additional commit. It could be you missed something at the last minute and threw up a new one, an automated process starts up, or just your typical race conditions. Reverting a commit means you either will blow up with those changes or you end up erasing every other commit as you have to force push to get it up.
This also means that this is a very fragile process and will break many times, usually at the worst times (when you have a rapid series of commits), and then you have to tell everyone to stop working while you fix it.
(A good sign is how much work you have to do to fight the CI process.)
Instead, I recommend you create a merge request (MR) against your branch and set up the rules to make sure that is valid before you merge it into your branch. That way, the process doesn't have to worry about future or past commits, it just says what you have in your merge request (which is another branch) can't be applied after merging it with branch-name.
In our team, we have many branches (main, next, release/2.3.4, release/2.4.0, etc.) and doing MRs against each one has worked out well. We do the merge requests against each of the release branches, and the CI process says it can merge and pass tests before it tries to commit, but then we can commit knowing that 98+% of the time, it will be fine.
And it doesn't require jumping through hoops.
Context
Our pipeline triggers:
trigger:
branches:
include:
- develop
- master
pr:
- master
Our pipeline acts based on some conditions which check which branch it's on, or what triggered the pipeline.
Commit to develop triggers bumps the version, commits back to develop, builds and artifacts
PR triggers a deployment to acceptance
Commit to master triggers a deployment to production
To not have the develop branch trigger itself it commits with [skip ci] in the commit message.
I have verified that it works when I merge a PR that does not contain any [skip ci] commits. So the trigger itself is functional.
Problem
When we merge the PR to master it does NOT trigger the CI trigger at all. In the azure devops panel it never shows up, indicating that it is ignored.
Removing the [skip ci] commit makes this problem go away, but introduces the problem of the pipeline triggering itself constantly.
Our repository is in GitHub, preventing me from manually filtering out based on commit author or something.
I'm somewhat perplexed that a merge commit, containing an older commit with [skip ci] in it, is preventing the trigger from firing.
Am I misunderstanding expected behavior here?
I'm open to workarounds as well.
Apologies if this is answered somewhere already, but I could not find anyone with this exact issue.
Commit log
In red: a merged PR without a [skip ci] commit -- this correctly triggers CI master branch (see underlined commit with checkmark)
In yellow: a merged with a [skip ci] commit -- this does not trigger CI master branch (see underlined commit without checkmark)
Neither merge commits contain more then the title in the commit message.
Azure DevOps Pipeline log
I've marked the same sections as in the github screenshot for clarity. As you can see an Individual CI for master is missing in the yellow section.
My guess is that the merge commit generates a comment listing all the commit messages for all the included commits. Hence, the commit message of your merge then contains a [skip-ci].
I'm guessing the ideal way to handle this is to either edit the commit message prior to merge or to make sure your skip-ci marker is in the description part of the original commit messages.
This is the first.line of the commit
[skip-ci] < on the second line
That way it gets omitted in the merge commit message.
When we merge the PR to master it does NOT trigger the CI trigger at all. In the azure devops panel it never shows up, indicating that it is ignored.
I could almost reproduce this issue on my side with Github repo.
If we set the trigger for the main pipeline like:
trigger:
branches:
include:
- develop
- main
pr:
- main
In order to avoid CI trigger from develop branch, we add [skip ci] in the commit message when commit for develop:
Obviously, our pipeline will not be triggered. It also works fine.
But, if we create a PR to the main branch without the [skip ci] in the context when create the PR:
The result is only have the PR trigger for the main branch.
The CI for main branch after PR complete are not triggered：
If we do not add the [skip ci] when we submit from develop branch, the CI for main branch will be triggered after PR completed.
Then I create a similar sample with Azure devops Git repo. I got the different result.
Regardless of whether we include [skip ci] in the PR context, the CI build of the Main branch will be triggered after the PR is completed. This is the expected result, which is obviously different from the result of the github repo
So, we are not sure if this is an issue or default behaver. I have submit a new ticket about it:
https://developercommunity.visualstudio.com/t/Azure-DevOps-Pipeline-not-triggered-for-/1400393
I have now circumvented this issue by removing the [skip ci] commit and using some exclude path filters on the the CI triggers.
This introduces some other minor issues, but for now this works for us. Obviously this isn't a real solution, so I won't mark anything as an answer for now.
I am working on my master branch and have some uncommitted changes inside the master branch. I have already created a feature branch and I am able to switch to my feature branch using the git checkout feature_branch command. I have couple of doubts here which I am listing below:
Why am I seeing the uncommitted changes in my branch when I have made my changes inside my master branch. If I commit my changes in the master branch and switch to my feature branch, I do not see the committed changes specific to master. I am expecting the same behavior for uncommitted changes also.
I came across the stash command in Git and there it was mentioned that if you have any uncommitted changes inside the master branch, and would like to switch to some other branch, git will not allow you and hence you need to stash the changes inside the master branch and then only switch to the development branch. I did not face this issue. Am I missing something here and if so, what is the significance of using the stash command?
If I commit my changes in the master branch and switch to my feature branch, I do not see the committed changes specific to master. I am expecting the same behavior for uncommitted changes also.
That's not a sensible behavior. Uncommitted changes are by definition not made to a branch. Branches are pointers to commits, and there is no commit associated with uncommitted changes. They are made to your working directory and have nothing tying them to any branch. They aren't even associated with Git. Until you commit (or stash) them, Git does absolutely nothing to track them, and it will never try to manage them for you.
I came across the stash command in Git and there it was mentioned that if you have any uncommitted changes inside the master branch, and would like to switch to some other branch, git will not allow you and hence you need to stash the changes inside the master branch ...
That's wrong. Stashes don't exist inside any branch. There is one global pool of stashes.
... I did not face this issue.
You will only be prevented from switching branches if doing so would cause your uncommitted changes to be overwritten.
Am I missing something here and if so, what is the significance of using the stash command?
You only need to worry about stashing your changes if they affect any files that would be changed by switching branches. If you have modifications to a file that is identical between two branches, switch from one branch to the other will not require a stash. If the file is different on your other branch, Git will not let you switch branches, as this would destroy your uncomitted changes.
It is safe to try switching branches, and if Git warns you that "uncommitted changes would be overwritten" and refuses to switch branches, you can stash your changes and try again.