Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About tyler

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Repo setup look fine. I'm doing a manual build with a custom revision set. https://confluence.atlassian.com/bamboo/running-a-plan-build-manually-289276898.html#Runningaplanbuildmanually-Runningacustomizedmanualbuild Searched around and found a very old log with custom revision working from 2018. So yes, definitely was with a previous version but I can't say which one.
  2. The only thing I can think of is we have 3 build agents and commonly we're doing custom builds for a past revision. Here's a case I just tried: - Latest cs is 23277 and Agent 1 is currently building it - Agent 2 last built 23275 - I Run Customized with 23275 as the revision - Agent 2 starts the build and updates to 23277, even listing 23277 as the custom revision like in my previous post. Tried it on another plan: - Latest cs is 23277 - Agent 3 last build 23276 - Run Customized with 23275 as the revision - Agent 3 picks it up and updates to 23277 instead Nothing else of much interest. Single stage and job in bamboo. First task is checkout repo. Repo using main branch, no other branches active. Repo is linked across all build plans. Seems to happen on all build agents and plans.
  3. Bamboo and the plastic plugin have not been upgraded. Plastic server and clients build agents have both been updated. There's a relevant conflict evident in the build logs and summary. Note the metadata is correct, but then the build summary lists the wrong custom revision. Bamboo build metadata: customRevision 22530 dependenciesDisabled true ManualBuildTriggerReason.customRevision 22530 Build summary: Custom variables Custom revision 22538 Log: simple 02-Mar-2020 15:23:43 Starting task 'Checkout Default Repository' of type 'com.atlassian.bamboo.plugins.vcs:task.vcs.checkout' simple 02-Mar-2020 15:23:43 Checking out into C:\bamboo-agent-home\xml-data\build-dir\FIR-PKG-JOB1 simple 02-Mar-2020 15:23:43 Updating source code to revision: 22538 simple 02-Mar-2020 15:24:01 Updated source code to revision: 22538 simple 02-Mar-2020 15:24:01 Finished task 'Checkout Default Repository' with result: Success Also taken from earlier in the log is all the variables: bamboo_repository_revision_number=22538 bamboo_repository_32771_revision_number=22538 bamboo_repository_32771_previous_revision_number=22538 bamboo_planRepository_revision=22538 bamboo_repository_previous_revision_number=22538 bamboo_planRepository_previousRevision=22538 bamboo_planRepository_1_revision=22538 bamboo_repository_32771_name=Firestorm bamboo_planRepository_1_previousRevision=22538 bamboo_planRepository_branchDisplayName=/main bamboo_planRepository_1_type=plasticscm bamboo_customRevision=22530 From all of this it looks like a bamboo bug, but I'm 99% sure this used to work and bamboo hasn't been updated while plastic has.
  4. The plastic client for all of the build agents is: The bamboo machine is not a build agent but has plastic client installed: "Plastic SCM plugin - 5.14.1 Vendor: Codice Software"
  5. I'm seeing an issue where when I try and build a specific changeset in bamboo it syncs to the latest changeset instead. This used to work, but I'm guessing it broke sometime after a plastic server update. Is there an updated version of the plugin I can use? Or a fix/workaround? Thanks! plugin: bamboo-plasticscm-plugin-5.14.1 server: bamboo: version 6.7.1 build 60705
  6. The most important thing I'm trying to track is to know when source files were added or removed. Secondarily to that it would be nice to track the changeset number of the last built binary. So my approach was to use a checkin trigger update the changeset in a file whenever source files are added or removed. Then when clients that sync to that changeset the build tools notice the change in the version file and trigger a proper rebuild (regenerate project files in unreal). This approach gives the added bonus of easily tracking the changeset number in a header file that the binary can reference. The only problem I ran in to with this is that the trigger needs to change and add a file to a checkin that was not specified as part of the checkin. I'll look in to adding attributes or labels, but unless I can communicate to the build tools that source files were added or removed between the old/new changesets then it's moot. It's worth noting that this needs to be a fast operation, or else I might as well rebuild every change all the time.
  7. Thanks for the reply Pablo. I believe I do need the changeset file versioned because we only conditionally change it (ie. on source file changes, not on data/asset changes) and I want to know the changeset of the latest binary (as well as check to see if it differs from the previous workspace binary cs). I'm not terribly concerned with the changeset being correct 100% of the time, so if the rare concurrent checkin throws it off then no big deal. Is it possible to ensure that a file that changes from a before-clientcheckin trigger gets included in the checkin? Simply doing a checkout from the trigger didn't work when I tried it. The change was simply left in the workspace and the user would need to do another checkin to submit the changeset file. Thanks! Tyler
  8. I'm trying to add a trigger that will update a versioned file with the submitted changeset number upon each checkin. I've tried using a before-clientcheckin where I update the file (although the changeset is unknown) and then execute a "cm co" with changed file, but the file isn't included in the checkin. I've also tried doing the same thing with an after-clientcheckin trigger with an added "cm ci" but both times it fails to either include the file or submit another checkin. Is there any way to do this? I basically just want to automatically write the latest changeset to a file and keep it in source control.
  • Create New...