I am trying to prevent release version override.
One of the options is to check the checksum, and if it is different (which mean - new file under the same name), fail the build.
Is it possible?
You don't need to compare checksums for that. Just configure the permissions to prevent deletions. This will effectively prevent overrides of released artifacts.
Related
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!
I have a situation where I would like to ignore specific folders inside of where Flyway is looking for the migration files.
Example
/db/Migration
2.0-newBase.sql
/oldScripts
1.1-base.sql
1.2-foo.sql
I want to ignore everything inside of the 'oldScripts' sub folder. Is there a flag that I can set in Flyway configs like ignoreFolder=SOME_FOLDER or scanRecursive=false?
An example for why I would do this is say, I have 1000 scripts in my migration folder. If we onboard a new member, instead of having them run the migration on 1000 files, they could just run the one script (The new base) and proceed from there. The alternative would be to never sync those files in the first place, but then people would need to remember to check source control to prior migrations instead of just looking on their local drive.
This is not currently supported directly. You could put both directories at the same level in the hierarchy (without nesting them) and selectively configure flyway.locations to achieve the same thing.
Since Flyway 6.4.0 wildcards are supported in flyway.locations. Examples:
db/**/test
db/release1.*
db/release1.?
More info at https://flywaydb.org/blog/organising-your-migrations
I need some advice about how to clean up an old Wix project that hasn't been managed very well. One problem is that the project currently has multiple entries for the same files, going to the same location. For example, several .wxs files in the project will define a new component for foo.exe, each using a different GUID and each sending this file to the same DirectoryRef. This hasn't yet created any issues, but now I want to use patches (MSPs) in our product and this sort of thing messes with their operation.
I'm wondering about the best way to resolve this without breaking upgrades (since all previous installers have gone out like this). If I simply remove all the duplicate components, we get undefined behavior during an upgrade. I think what's happening is that removing one or more duplicate entries will cause the installer to generate delete operations for that file. Even if the remaining entry for the file is a new version, there is no guarantee in the order of operations during the install. So some of these files will first get updated, then one or more delete operations will remove the updated file. Thus at the end of the upgrade several files will be missing. Running a repair immediately afterwards will restore the files, since the installer knows they are supposed to be there.
I imagine one way to resolve this is to do a one off "hack" in our next release, where we copy these files into a secondary location, then run a custom action post install that copies the files from the secondary location into the primary and delete the temporary directory.
Is there a cleaner way this could be resolved?
What you are likely going to have to do is use validation to identify all the duplicates and fix them. Then change your upgrade to be a major upgrade with the earliest possible scheduling. You may also have to change your install location to a slightly different directory to get around component reference counts breaking.
Once clean you should be able to go back to minor upgrades and start thinking about patching. An alternative would be "fake" patches. I've used an MSI that doesn't publish itself as a hotfix method very successfully. It breaks a lot of rules but can be useful for organizations that don't care about patching rules and just want to make the business happy.
I would like to skip publishing an artifact if it already exists in the repository, but as far as I can see from the documentation there isn't a way to do this. There is an overwrite attribute, but if set to false that causes the publish to fail if the artifact exists. I definitely don't want to overwrite the artifact, either.
I've looked into using <ivy:info> and <ivy:findrevision> to see if the artifact exists and set a property I can use on my publish target (as an unless attribute, for example), but neither of these tasks allows me to specify the repository to check.
I'd rather not resort to using an external taskdef, like antcontrib's try/catch tasks.
Does anyone have any other suggestions?
Info and findrevision allow the settingsRef-attribute. So you could use an extra settings-file that only references the resolver you need (via ivy:settings and ivy:configure) and use that settingsRef in your task.
Why would you run the "publish" task if you don't intend saving what you built?
I use the buildnumber task to ensure that my version number is incremented automatically based on what was previously published.
There is a cruisecontrol plugin that checks for changes to snapshot dependencies, triggering a build if required. This involves using the Maven embedder to download the dependencies, then checking the timestamps of the snapshot files in the local repository. This works ok, but involves downloading all the parents and dependencies to check some timestamps.
I'm working on a distributed CI system (e.g. Bamboo/Buildforge) and would like to avoid downloading the entire dependency hierarchy to check if a build is required. It is possible to determine the build date of a snapshot dependency by checking the maven-metadata.xml on the remote repository.
Are there any plugins or tools to streamline this process?
Assuming you're using maven as your build process, you want a plugin to do the checking and conditional build.
I don't know of any maven plugin that will do exactly what you want. However,
you should be able cobble together a couple plugins for the same effect.
Use the exec plugin with "wget" to fetch the maven-metadata.xml.
Then use the xslt plugin to transform the resulting XML into a boolean value that will indicate whether or not an update has occured. You'll want to XPath to the //metadata/versioning/lastUpdated node and compare it to the current date and time. Finally, you'll need to examine the resulting transformed XML to determine if you should proceed with the build.
Find those plugins at http://mojo.codehaus.org/plugins.html
It looks like Mercury provides the higher level API I was looking for.
Mercury provides an implementation-neutral way to access GAV-based repositories, including AV repositories, like OSGi. OSGi access is not implemented yet. By access I mean reading artifacts and metadata from repositories and writing artifacts to repositories, metadata is updated by writes.
All the calls accept a collection of requests as an input and return an object that hides getResults, that normally is a map< queryElement, Collection > response. The response object has convenience methos hasExceptions(), hasResults(), getExceptions(), getResults()
One of the key building blocks is a hierarchy of Artifact data:
ArtifactCoordinates - is truly the 3 components GAV
ArtifactBasicMetadata - is coordinates plus type/classifier plus convenience methods like hash calculation and such
ArtifactMetadata adds a list of dependency objects, captured as ArtifactBasicMetadata
DefaultArtifact implements Artifact interface and adds pomBlob (byte[]) and file, that points to actual binary