Does anyone know if it is possible to update source files during a build (from an external source for e.g. like checking if there are new translations and merging those in) and then merge those changes to a git branch via a Pull request with TeamCity as part of the build steps?
TeamCity has an 'Automatic Merge' feature. Please have a look at the documentation and the related blog post
Related
On Github we can set automatically deletion of branches after merge for a repository (like explained here). I want to do this for 30 repositories.
Is there a way to do this by script ?
I typically would like to add a file to each repository.
I think you can do this relatively easily with a script. You can use the GitHub CLI for this. There is the following command with which you can switch on the deletion of the branch after a successful merge for a repository:
gh repo edit [<repository>] --delete-branch-on-merge
If you want to start with the CLI, I guess this is a good starting point.
I'm working with Cake and Teamcity and I'm trying to access which branch a GitHub PR is targeting
Been trying to find a GitHub API wrapper for Cake do to the job, or a plugin/script to TeamCity to populate some parameter with the value, but no luck so far.
Is there any good wrapper for Github PR in Cake or TeamCity that i have missed?
I'm certain there is nothing that you have missed.
The question would be - before searching for how to do this in Cake - how to obtain the information in the first place.
If you were building on GitHub Actions, there is the github.base_ref which GitHub populates for PRs and which would contain exactly what you are looking for.
Now, I don't know how TeamCity does the checkout so I can probably not really help you. What I can do is give you a pointer:
What AppVeyor does when building a PR is this:
git clone -q <url of repo>
cd <name-of-repo>
git fetch -q origin +refs/pull/<gh-id-of-pr>/merge:
git checkout -qf FETCH_HEAD
If you - in that state - do
git branch --contains HEAD^1
the output (at least in my tests) is:
* (HEAD detached at FETCH_HEAD)
develop
As said above, I am not sure what TC does for a PR build but I guess you'd need something along the above lines.
I, personally, would try to get the required information using git commands before checking what the GitHub API can do.
In the end I found and used the Octokit SDK for dotnet
https://github.com/octokit/octokit.net
As I for #Nils answer would also need the authorization for the repo to run the GIT commands, i went with a higher level solution more native to Cake
I know that on Git in general it is possible to enable commit templates by modifying the git config file in the .git-folder. But as these folders are hidden in DevOps is this possible or even recommended in DevOps? If it is doable on DevOps is the process different?
In Git the process should be, modify git config to include:
[commit]
template = ~/.gitmessage
Agree with Tomasz, It is default git behavior, it's not Azure DevOps specific.
As a workaround:
Enable branch policy, it will reject developers push changes directly to the protected branches. Developers need create pull request to push the changes.
Configure pull request template file.
Update repo and create pull request to push changes.
Use pull request template to update the pull request description.
Then we can check it in the commit details.
Result:
It is not possible to edit .git/config file and store it in the remote repo, for everyone to clone it.
You can include instruction in ReadMe on your repo to change a config with
[commit]
template = ~/.gitmessage
once someone clones it.
I am creating jobs using Jenkins Organization Folders.
I want to continuously build against pull request.
However, when I create a pull request, it will be built automatically only the first time.
Even if I add commit to pull request, Jenkins does not build automatically.
I expect that build will work again when the commit is added to the branch that created the pull request.
I am using the following version of Jenkins / plugin.
Jenkins: 2.89.1
GitHub Branch Source Plugin: 2.3.1
GitHub Branch Source Plugin has the following settings.
Discover branches: Exclude branches that are also filed as PRs
Discover pull requests from origin: Merging the pull request with the current target branch revision
Discover pull requests from forks: Merging the pull request with the current target branch revision
Also, although I am using Github Enterprise, I think that the configuration of webhook is okay as the build runs instantly when creating the pull request for the first time.
There is two way to resolve this issue
1)
You have to configure your github repository so it inform jenkins of a new version: yourRepo/settings/hook&service/service ( the best practice)
or
2) you can configure your jenkins jobs so it check for diff time-to-time if the repo have been update :
yourJob/configure/Scan Repository Triggers/Periodically -> 10 min
In my project, we configure both, with a Periodically check of once a day
If you were talking about GitHub Organization folder, then
there is a section where you can configure automatic branch triggering.
We are using a private GitHub Organization as version control. When a task is assigned to a developer, they fork the primary repository, make their code changes, and submit a pull request to have the changes merged into the master branch of the primary repository.
We are also using TeamCity for CI. It is currently configured to kick off a build for a VCS commit, which builds, tests, and deploys the artifact to an artifact repository internally. To accomplish this, the Team City build configuration has multiple VCS roots installed; one for the primary and 1 for each developer's fork.
The problem is that Team City pulls from all of them when a commit is made assuming they are all necessary for the build instead of allowing you to only pull from the single repository that triggered the build. Any thoughts on how we can accomplish this without having to create n build configurations in Team City for each project (where n == number of developers working on a project)?
I see way to do this with preserving current workflow is turning off automatic checkout (VCS Checkout Mode), and checking out code manually in an additional command-line build step, with a parameter %teamcity.build.branch% (logical branch name).
I.e.:
git clone ...
git checkout %teamcity.build.branch%
Triggers will just start the job if there are changes in developer's VCS root, fulfill branch env variable; no automatic checkout will happen and then build step will check out only needed branch. Only works with one git URL.
After posting in the JetBrains forums, I was pointed to a blog that answers my question.
TL;DR: my approach of using feature branches does not work with GitHub's workflow. Instead, Forks and Pull Requests should be used. The blog referenced shows how you can use Team City to trigger off of a Pull Request. Simply add +:refs/pull/*/head to "Branch Specification" in your VCS Root and all pull requests to the Source repository will trigger your Build Configuration.