I have a build plan in Bamboo (5.10.0, build 51017), and in the end of my build process, I push changes to my Git repository (Bitbucket Server), with a message with the following format: <build key>: Commit performed by the build server..
My build plan key is AAB-AC, and the commit message always starts with the key of the build, such as AAB-AC7-JOB1-75 (${bamboo.buildResultKey}).
I have tried many different regular expressions in the Exclude changesets field of the Advanced options of my repository, but a new build is always triggered whenever a build completes.
Here are a few examples of the patterns I have tried:
^AAB-\S*-\S*-\d*:
^AAB-AC\S*-\S*-\d*:.*$
^AAB-AC
AAB-AC
^AAB-AC\S*-\S*-\d*:.*\n
^AAB-AC.*$
^AAB-AC.*-.*-.*:
Commit performed by the build server
For each of these regular expressions, whenever I run a build manually, a new build is started right after my build finishes and the Bamboo server enters an infinite loop and endlessly builds my app.
How can I make Bamboo ignore the commits performed by my build plan?
Thank you for your help!
Most of those should work, we use ^Tag:.*$ in "Exclude changesets" to exclude commits like "Tag: v1.0.0" from triggering a build.
This worked in Bamboo 4, but doesn't work since we upgraded to 5.10.2 build 51019. So my guess is that this is a bug in Bamboo
I finally managed to make this work...
I have branches on my plan and I found that branch plans have their own repository definition with their own Exclude changesets setting.
So I tried all the regex combinations for nothing since the value specified on the branch plan was used, and not the value I defined on the main plan...
It seems that the ^ character is used to negate the regex, instead of matching the beginning of the string...
So the pattern ^AAB-AC seems to match everything that does not contain AAB-AC
All the commits I pushed to my server that didn't contain AAB-AC were ignored
All the commits pushed by my build plan triggered a new build
So I fixed my regex and I updated all my branch plans and everything seems to work properly.
Thank you for your help,
Best regards!
Related
New to Gitlab CI/CD.
What is the proper construct to use in my .gitlab-ci.yml file to ensure that my validation job runs only when a "real" checkin happens?
What I mean is, I observe that the moment I create a merge request, say—which of course creates a new branch—the CI/CD process runs. That is, the branch creation itself, despite the fact that no files have changed, causes the .gitlab-ci.yml file to be processed and pipelines to be kicked off.
Ideally I'd only want this sort of thing to happen when there is actually a change to a file, or a file addition, etc.—in common-sense terms, I don't want CI/CD running on silly operations that don't actually really change the state of the software under development.
I'm passably familiar with except and only, but these don't seem to be able to limit things the way I want. Am I missing a fundamental category or recipe?
I'm afraid what you ask is not possible within Gitlab CI.
There could be a way to use the CI_COMMIT_SHA predefined variable since that will be the same in your new branch compared to your source branch.
Still, the pipeline will run before it can determine or compare SHA's in a custom script or condition.
Gitlab runs pipelines for branches or tags, not commits. Pushing to a repo triggers a pipeline, branching is in fact pushing a change to the repo.
Is it possible to use a variable as build trigger? I've tried and the build doesn't get triggered. If I remove the variable and insert a value, the build gets triggered as expected.
Aren't variables allowed here? $(Mapping.ServerPath) is set to MyRepo/Branches/MyBranch. $/MyRepo/Branches/MyBranch triggers the build correctly.
No. And why should they?
The specified path results in a poll action being performed on the static path.
You can use wildcards if needed.
The build should trigger on a change, hence CI trigger.
Making the path a variable, when would you provide it?
If it's just keeping a static value elsewhere, why not fill it in?
If you want to provide the path when calling the build.
Then you don't intend to use the CI option as intended?
No, it is not supported.
There is a user voice that you can follow: Allow Variables in Repository, variables and triggers Tab.
We have a microservice architecture with dozens of builds, it makes sense to be able to use a variable that we can update when we start our next iteration. With our branching strategy we have a new branch for each sprint and for each release. Changing the CI trigger in every build every couple weeks is inefficient.
We are using on premise TFS2018 and from everything I've seen this is not supported.
I divide this to two issues , but solving any one of them will solve the other.
Issue 1:
When I use the section at the bottom of the following picture and add "configurations to release", the build is not triggering release management.
I queried the build logs for hours, and saw that it stops the release when it founds out that the configuration "does not match current"
If ConfigurationsToRelease Matches Current
Initial Property Values
Condition = False
Final Property Values
Condition = False
Final Property Values
Condition = True
before more words, I will show a picture that sums it up:
the build definition and ms build logs
in a default case, where configuration to release is blank , release management would continue from this point and write in the logs "Release the build" (as a command that happened) and the build would trigger release management.
If you look at my tfs build configurations, you can see it's exactly the same as the upper regular ms build configurations , but still I get this error of a mismatch.
In any case I only have only one dialog to fill my configurations at in build definition as shown in the 'configuration dialog' in the above pic.
I succeeded to release once or twice this way in this same project the other day by adding release configurations, it somehow worked, but then stopped working (worked once or twice as a glitch I think like something is cached there) but 99% of the other attempts failed, it was always stopping my trigger from tfs to release since the first time I tried it a few months ago.
Has someone here experienced it? I looked in a lot of places and spotted only one guy that complained about it. His solution was to remove it (not exactly a solution)
Is there a build argument that can fix this? (/p:something=something)
Issue 2: if anyone can solve it in a way different than rm configurations , then I don't need issue 1 to be solved.
For any one who is interested why I even messed with release configuration section of build definition, it's because I want rm to wait for all transformations to happen before rm intervention, and this seems like a way to tell rm , ok dude , see there? you got 2 configurations to wait for their build.
The thing is that by default when that configuration section is blank, rm is getting in the way of tfs build and tfs build is getting in the way of rm, something like a circular wait. rm expects both transformed folders to exist in build outputs when tfs build is waiting for rm to finish it's run after the first build, tfs wants to continue building the second configuration (and transform) but rm is involved already , seeking for it's second configuration, breaking the build when fails to find it, hence the second configuration will never be created, while rm is still waiting for it and tfs build waits for rm and build breaks. confusing? read again and see the pic below cause it's interesting enough.
more info for clarity:
the next stage of RM is trying to get something from build outputs folder before it's already there.
for example , if i set Release build to true , it will only build the first configuration (a folder is created, picture below) , rm will succeed in first step (QA.Release), and continue strait to try and grab Release for its next stage, but it's not built yet by TFS Build , which waits for rm to finish it's weird intervention in the middle of tfs's build work . and like i said above, I'm sure I've seen it work once or twice in one of my attempted builds.
the tfs output folder whith release build flag on(only one transform happens) \ when off (all two transforms work) + rm error when on (circular wait)
If I understand your situation correctly I think your problem is that you are building multiple configurations. This breaks one of the core tenets of continuous delivery which is that for a given release you should build only once and deploy that same build to each stage in your pipeline, in sequence.
In order to do this your build needs to be stage agnostic, which in practice means all your configuration (eg database connection string) needs to be tokensised so that the correct value can be swapped in for the particular stage (QA, Release etc). I have a blog post series here that explains the full process (for a sample web application) in great detail.
i managed to solve issue 2 , and by doing so, issue 1 is no longer relevant .
i switched to ReleaseTfvcTemplate.12.xaml as a build template (found on your C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin)
and then the build finished all configurations before RM intervention .
truly seems like a bug in ReleaseDefaultTemplate.11.1.xaml , or this might be because i was using some additional msbuild arguments (which were needed) , or the fact i'm using slow cheetah to create transforms on a windows service (transformations are only introduced in web applications).
either way , i'm now able to perform advanced tasks , like using the transforms to add \ remove tags that should be different in production , for example , i can leave the use of diagnostics in the configuration file for qa use , and remove it for production to make the verbosity lower there . still am using RM PlaceHolders technique in conjunction to transformation technology , to enjoy both worlds where it comes to changes related to environments , but still keeping the principles by passing the same build (dlls) through all environments .
I'm working on something that is using Hibernate for database access. I've got everything set up and working so that I can use mvn hibernate3:hbm2ddl to build the database schema, and I'm using mvn liquibase:update to populate initial data into the database (DBUnit was my first try but I couldn't get it to work with Oracle and Liquibase just worked first time).
My problem is that if I execute hbm2ddl to drop and re-create the schema then the Liquibase DATABASECHANGELOG tables are left intact, meaning that Liquibase won't re-create the data the next time it's run. To get around this I've configured up mvn sql:execute to perform a drop on the two tables in question, but this means that to be safe if I want to build the database from scratch I now need to execute "mvn hibernate3:hbm2ddl sql:execute liquibase:update"
What I'd really like is to be able to configure up something that will execute the sql:execute command when the hibernate3:hbm2ddl command is run, so that I know that doing that one command will leave me in a nice clean database state. Failing that, a configuration that will run a number of commands in sequence automatically, so I could configure up for example "mvn execute:db-rebuild" to run the three commands above automatically.
I've seen mention of mojo-executor but no examples on actually how to use it. I'm not even sure if it's the right tool for what I want...
Why don't you bind these different things to a particular thing like the integration-test phase. The order of the plugins will define the order of exectutions. Than you get rid of hand calling mvn ...
We have a particular file, say X.zip that is only modified by 1 or 2 people. Hence we don't want the build to trigger on every check-in, as the other files are mostly untouched.
I need to check for a condition prior to building, whether the checked-in item is "X.zip" or not.. if yes, then trigger a build, else don't. We use only CI builds.
Any idea on how to trigger the build only when this particular file is checked-in? Any other approaches would be greatly appreciated as i am a newbie in TFS...
Tara.
I don't know of any OOTB feature which can do this, what you would need to do is write your own custom MSBuild task which is executed prior to the build running (pre-build action).
The task will then need to use the TFS API to check the current check in for the file you want and if it's not found you'll have to set the task to failed.
This isn't really ideal as it'll indicate to Team Build a build failure, which, depending on whether you're using check in policies, may be unhelpful. It'd also be harder to at-a-glance work out which builds failed because of the task and which failed because of a real problem.
You can change the build to occur less frequently rather than every check in, which will reduce load on your build server.
Otherwise you may want to dig into Cruise Control .NET, it may support better conditional builds.
If you could move X.zip into it's own folder, then you could set up a CI build with a workspace that only looked at the folder containing X.zip.
You would then need to add an explicit call to tf get to download the rest of the code as Team Build only downloads what the workspace is looking at.
But this might be simpler than the custom task approach?