I'm trying to automate deployments using Concourse-CI.
I have a go application that is checked into a local Gitlab with two branches (master and develop).
I have a pipeline setup for the develop branch that runs go unit tests and if they pass i want to automatically merge the changes from the develop branch to the master branch and tag it with the latest version.
Here is what I have so far:
jobs:
- name: run-unit-tests
public: true
plan:
- get: source-master
- get: source
trigger: true
- put: discord
params:
channel: "((channel_id))"
color: 6076508
title: Concourse CI
message: |
Starting Unit tests for manageGameData
- task: task-unit-tests
file: source/ci/tasks/task-unit-tests.yml
on_success:
do:
- put: discord
params:
channel: "((channel_id))"
color: 6076508
title: Concourse CI
message: |
All Unit tests passed for manageGameData
- put: version
params:
bump: minor
- get: version
- put: source-master
params:
merge: source
repository: source-master
tag: version/number
The problem is that this only tags the master branch with the new version.
Is there a way to merge the develop branch to master?
I guess i didn't understand the documentation at first but the answer was pretty easy.
- get: source-master
- get: source
- put: source-master
params:
repository: source
First you have to get both branches in this case master and develop. Then you push the source local repo (a folder on the concourse worker) to master by using put.
There is no need for the merge parameter and i had the wrong repository parameter.
Hope this helps someone else.
Alternatively you could use just scripts for more complex git commands.
platform: linux
image_resource:
type: docker-image
source:
repository: concourse/buildroot
tag: git
run:
path: /bin/bash
args:
- -c
- |
set -eux
git clone https://user:passw#repo.git
git config --global user.name "UserName"
git config --global user.email "email#your.com"
git checkout master
git merge hotfix
Related
GitHub allows for creating PR templates. Is it possible to do the same, but for pull request reviews?
An example of such would be adding a review checklist, like the following:
- [] Have all the GitHub checks passed?
- [] Is there any redundant code?
- [] Could any optimization be applied?
In GitHub, there are no templates for pull request reviews. And, this makes sense, because reviews directly belong to pull requests.
But you can run a GitHub action when a draft PR is changed to the ready for review state, for example with:
on:
pull_request_target:
types:
- ready_for_review
To create a comment with checkboxes in this step, use marocchino/sticky-pull-request-comment.
I have tested it in this PR and I am excited about how well this is working.
Full example:
name: "Pull request checklist"
on:
pull_request_target:
types:
- ready_for_review
jobs:
pull_request_info:
runs-on: ubuntu-latest
steps:
- name: Extract branch name
shell: bash
run: echo "##[set-output name=branch;]$(echo ${GITHUB_HEAD_REF})"
id: extract_branch
- name: Checkout repository
uses: actions/checkout#v3
with:
fetch-depth: 0
- name: Show checklist
uses: marocchino/sticky-pull-request-comment#v2
with:
header: show_checklist
message: |
- [ ] Checklist item 1
- [ ] Checklist item 2
For more options, check out the:
Sticky pull request comment repo
GitHub actions workflow events documentation
I have a GitHub workflow where a PR is created each day to update some dependencies.
The problem is that I have to merge it manually. The PR gets an auto-approve tag.
Next I can click "Merge pull request". If I go to settings > branches > main > and I enable require approvals (1). Then I can enable "Auto-merge" for the repo. But it does not fully merge since it requires an approval. So I have to turn it off again.
I'm not sure how this flow is working. I just want that it gets merged automatically. In my settings I have already enabled "Allow auto-merge".
This is a part of my upgrade-main.yml.
- name: Create Pull Request
id: create-pr
uses: peter-evans/create-pull-request#v3
with:
token: ${{ secrets.PROJEN_GITHUB_TOKEN }}
commit-message: |-
chore(deps): upgrade dependencies
Upgrades project dependencies. See details in [workflow run].
[Workflow Run]: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}
------
*Automatically created by projen via the "upgrade-main" workflow*
branch: github-actions/upgrade-main
title: "chore(deps): upgrade dependencies"
labels: auto-approve
body: |-
Upgrades project dependencies. See details in [workflow run].
[Workflow Run]: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}
------
*Automatically created by projen via the "upgrade-main" workflow*
author: github-actions <github-actions#github.com>
committer: github-actions <github-actions#github.com>
signoff: true
We have more number of common upstream pipelines - pipleline-a, pipleline-b, pipeline-c, pipeline-d … each in its own repository - repository-a, repository-b, repository-c, repository-d…
My target pipeline, say pipeline-y in repository-y, has a dependency on these upstream pipelines artifacts and the target pipeline needs to build when there is a change to any of the upstream libraries and the corresponding upstream pipeline builds successfully.
In other words, target pipeline-y needs to be triggered if any of the upstream pipelines completed successfully due to changes in them (CI triggers for upstream libraries work fine in their own pipelines).
We currently achieved this, using the resources pipelines trigger in the target pipeline-y, as below:
Upstream Pipeline - pipeline-a.yml
trigger:
- repository-a*
steps
- task: Maven#3
inputs:
mavenPomFile: 'pom.xml'
publishJUnitResults: false
javaHomeOption: 'JDKVersion'
mavenVersionOption: 'Default'
mavenAuthenticateFeed: true
effectivePomSkip: false
sonarQubeRunAnalysis: false
goals: 'package deploy'
Target pipeline-y.yml resources section
resources:
pipelines:
- pipeline: pipeline-a
source: pipeline-a
trigger:
branches:
- 'pipeline-a-v1*'
- pipeline: pipeline-b
source: pipeline-b
trigger:
branches:
- 'pipeline-b-v1*'
- pipeline: pipeline-c
source: pipeline-c
trigger:
branches:
- 'pipeline-c-v1*'
- pipeline: pipeline-d
source: pipeline-d
trigger:
branches:
- 'pipeline-d-v1*'
- pipeline: pipeline-e
source: pipeline-e
trigger:
branches:
- 'pipeline-e-v1*'
This works fine.
My question is, as we add more upstream common libraries, we have to update the resources section in the target downstream. When there are new versions of upstream libraries, we have to modify the version in resources-pipelines-pipiline-trigger - branches from “pipeline-a-v1” to “pipeline-a-v2”.
Is there a better way to do this? Can a variable be used in the resources-pipelines-pipeline-trigger - branches - example pipeline-a-$(version) . Can version be derived using Build system variables as below:
I tried
variables:
version: $[replace(variables['Build.SourceBranchName'], variables['Build.Repository.Name'], '')]
It did not seem to work.
It's not possible to dynamically specify resources in YAML.
A suggestion could be to use REST API hooks when new pipelines are added. Then trigger a program that generates new YAML for pipeline-y.yml.
I'm using multi branch resourcing in a concourse pipeline like so:
resources:
- name: my-resource
type: git-multibranch
source:
uri: git#github.com.../my-resource
branches: 'feature/.*'
private_key: ...
ignore-branches: ''
How can I access the branch the resource is on at the time the job runs? like so:
jobs:
...
outputs:
- name: my-resource
params:
GIT_BRANCH: {BRANCH-GOES-HERE}
I'm looking to access it via something like my-resource.branch but haven't found any thing that works yet
I have setup pipeline in Concourse with some jobs that are building Docker images.
After the build I push the image tag to the git repo.
The problem is when the builds come to end at the same time, one jobs pushes to git, while the other just pulled, and when second job tries push to git it gets error.
error: failed to push some refs to 'git#github.com:*****/*****'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
So is there any way to prevent concurrent push?
So far I've tried applying serial and serial_groups to jobs.
It helps, but all the jobs got queued up, because we have a lot of builds.
I expect jobs to run concurrently and pause before doing operations to git if some other job have a lock on it.
resources:
- name: backend-helm-repo
type: git
source:
branch: master
paths:
- helm
uri: git#github.com:******/******
-...
jobs:
-...
- name: some-hidden-api-build
serial: true
serial_groups:
- build-alone
plan:
- get: some-hidden-api-repo
trigger: true
- get: golang
- task: build-image
file: somefile.yaml
- put: some-hidden-api-image
- get: backend-helm-repo
- task: update-helm-tag
config:
platform: linux
image_resource:
type: registry-image
source:
repository: mikefarah/yq
tag: latest
run:
path: /bin/sh
args:
- -xce
- "file manipulations && git commit"
inputs:
- name: some-hidden-api-repo
- name: backend-helm-repo
outputs:
- name: backend-helm-tag-bump
- put: backend-helm-repo
params:
repository: backend-helm-tag-bump
- put: some-hidden-api-status
params:
commit: some-hidden-api-repo
state: success
- name: some-other-build
serial: true
serial_groups:
- build-alone
plan:
- get: some-other-repo
trigger: true
- get: golang
- task: build-image
file: somefile.yaml
- put: some-other-image
- get: backend-helm-repo
- task: update-helm-tag
config:
platform: linux
image_resource:
type: registry-image
source:
repository: mikefarah/yq
tag: latest
run:
path: /bin/sh
args:
- -xce
- "file manipulations && git commit"
inputs:
- name: some-other-repo
- name: backend-helm-repo
outputs:
- name: backend-helm-tag-bump
- put: backend-helm-repo
params:
repository: backend-helm-tag-bump
- put: some-other-status
params:
commit: some-other-repo
state: success
-...
So if jobs come finish image build at the same time and make git commit in parallel, one pushes faster, than second one, second one breaks.
Can someone help?
note that your description is too vague to give detailed answer.
I expect jobs to concurrently and stop before pushing to git if some other job have a lock on git.
This will not be enough, if they stop just before pushing, they are already referencing a git commit, which will become stale when the lock is released by the other job :-)
The jobs would have to stop, waiting on the lock, before cloning the git repo, so at the very beginning.
All this is speculation on my part, since again it is not clear what you want to do, for these kind of questions posting a as-small-as-possible pipeline image and as-small-as-possible configuration code is helpful.
You can consider https://github.com/concourse/pool-resource as locking mechanism.