I am trying to integrate Atlassian Bamboo with a CloudFormation template that creates and deploys environments in AWS. One of the tags we add to the VPCs and EC2 instances is the name of the engineer that triggered the build.
I can't find a bamboo variable that contains the name of the user that triggered a build. I found one that has the username of the person who created a release in Jira, but this isn't what I want.
https://confluence.atlassian.com/display/BAMBOO/Bamboo+variables
Is there a way to get this variable?
You are looking for ManualBuildTriggerReason.userName, that will be the name of the person who manually triggered a build but if it was off a trigger this will not be present.
For the name of the person who didn't trigger the build manually but did it through a source code commit then you could probably be:
git log <commitFrom>..<commitTo> --format="%aN <%aE>" --reverse
And then you could use repository.revision.number for the current revision and then repository.previous.revision.number for the previous revision.
Related
I've written several pipeline templates that our development teams use in their projects and what I've found is that if I make a change
in a template to fix a bug, when we "retry" a job it doesn't pick up the latest changes from the template. The only way the job will receive the latest
reference to the template is if we push another commit to the developer's project.
Is there a flag or parameter we can set so that it always picks up the latest copy?
Here is what our gitlab yml looks like in the developer projects.
include:
- project: 'ops/awesome-pipelines'
file: 'pipelines/fresh_apps.yml'
Is there a flag or parameter we can set so that it always picks up the
latest copy?
I think the functionality that you are trying is not possible.
Quoting the gitlab docs https://docs.gitlab.com/ee/ci/yaml/index.html#includefile
When the pipeline starts, the .gitlab-ci.yml file configuration
included by all methods is evaluated. The configuration is a snapshot
in time and persists in the database. GitLab does not reflect any
changes to the referenced .gitlab-ci.yml file configuration until the
next pipeline starts.
Template changes are only reflected in new pipelines. The benefit of this is that you can reliably retry jobs and assure that template changes won't change the behavior of a retry.
You don't necessarily need to push another commit, but you will have to start another pipeline (for example, manually running a new pipeline for a branch or MR).
I have a gitlab job that is trying to trigger a downstream pipeline from another project. The 2 project are at the same location. The problem is that the trigger job stays in pending mode, never triggering the correct pipeline. The job is has follow :
trigger_test:
stage: Test
trigger:
project: Name with space/nameWithoutSpace/ProjectToTrigger
The field project is supposed to be the full path to the project so I tried exactly that but I don't know if the spaces in the name affects it or not. I tried with "" but It didn't work. None of the projects are private so they should be able to access themselves.
I have no rights to access the projects configs so it makes it hard. Maybe it is because of my access rights? Any tips will be welcomed!
EDIT Secustor got it right. Using the project slug that i found in the url of my project I wanted to trigger worked for me.
The Gitlab documentation says the following about GIT_STRATEGY: none:
none also re-uses the project workspace, but skips all Git operations (including GitLab Runner's pre-clone script, if present). It is mostly useful for jobs that operate exclusively on artifacts (e.g., deploy). Git repository data may be present, but it is certain to be out of date, so you should only rely on files brought into the project workspace from cache or artifacts.
I'm still a bit confused about how this is supposed to work. If the source code is not guaranteed to exist, then there might be no source in the project workspace and thus the .gitlab-ci.yml file would also be missing. Without a build script the job must fail. If the source is missing only part of the time depending on external factors, the job will fail randomly, which is even worse than failing every time. However, if it fails every single time then what's the point of the feature?
Another possibility I see is that .gitlab-ci.yml might be injected at runtime, so that even without a fresh copy of the repository there would be a build script. If so, could I define further files from my repository to inject into the build process? What are the restrictions on these particular jobs?
Yes, the .gitlab-ci.yml file is not copied onto the system just like all the other files. But that doesn't matter as the job is not run from the file. The job is run as a script on your target (and even before that as it defines the target it will run on). It is not possible to copy only selected files without a git clone although you may want to copy the files from some other server.
A good example of when you want to run GIT_STRATEGY: none are things like slackchat notifications as last stage of a build when you really don't want to clone gigabytes of repository data just to push a notification.
I have a build chain of 4 build configurations, which correspond to different teams' tasks. The idea behind the configurations is this:
Run the build itself
Move build to staging
QA approved
Release
Each of those configurations have different responsible people. People not responsible for a given configuration should not be allowed to run it.
I know I can define roles on project-level, but here I need to define it on a build configuration-level. Is that possible?
Thanks
You can create subprojects for each configuration and then assign roles corresponding to restrictions.
You can add precondition step to each job where check username and fail step and job if user not allowed to run this job.
I made the second approach in similar case.
I have a plan in Bamboo that starts whenever changes are made to the attached repositories (via polling).
Now, on each build, if successful, a CHANGELOG file is updated in the repo, which in turn, triggers another build. How can I omit certain files from Bamboo's polling, so that a build isn't started if changes are found for those files? Because otherwise, I enter in infinite loop, with a change to CHANGELOG triggering another build which in turn updated CHANGELOG and so on.
If this is not possible, what other viable solutions are there? Is it possible to attach a shell script somewhere before the build starts to check whether it's desired to start a new build?
It turned out that this was simpler than I've thought. In Plan Configuration, in the Repositories tab, on each repository, under Advanced, there is an Include / exclude files input where you can Customise what files Bamboo uses to detect changes. By adding a regular expression there, I got everything solved and working as expected.
Bamboo pattern matching reference: https://confluence.atlassian.com/display/BAMBOO/Pattern+matching+reference
The Bamboo Documentation says:
Bamboo will ignore build triggers if the local working copy and the
repository copy have the same revision numbers.
This might not be the best solution, but you might add an additional task at the end of the job/build which updates the repository again to avoid triggering a new build.
I'm not sure if this would then skip builds from repository updates which occur during the current build.