Child pages
  • fbc-config-upgrader-tests
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


Pipeline stage to test that AM's FBC (file-based config) can be upgraded (and then used with AM successfully) after every commit.  This stage will fail if required openam-config-upgrader rules are missing from fbc/master.groovy.


Deployments of (file-based) AM require an upgrade mechanism.  The openam-config-upgrader (released within the can upgrade the FBC configuration files.  To ensure that the upgrader rules are kept up to date the fbc-config-upgrader-tests stage has been added to the postCommit pipeline.  The premise is that a known baseline FBC can be upgraded, using the tool and rules, and then used to successfully start up the latest version of AM.  The rules should be idempotent; so running multiple times will produce the same end result.

See  AME-18809 - Getting issue details... STATUS  for the implementation.

Test failure is an indication to the code committer that a new file based configuration upgrade rule is required on master.  (There is a dependency on completion of  AME-18785 - Getting issue details... STATUS )


The test has its own deployer UpgradedFBCAmDeployer which can be called by the Tests' CLI.  The AM-7.0.0 baseline configuration is in the OpenAM git repository along with scripts to generate a new configuration if/when required.  At the time of writing there is one upgrade rule to set the configuration version.


  • Start with a known set of configuration at a fixed version.  (It is possible a new baseline will be required from time to time e.g. new major release)
  • Run the upgrader with the "master" set of rules
  • Start AM with the upgraded configuration
  • Verify that AM has started correctly

N.B. the setup requires an external datastore i.e. not embedded datastore

  • This is because setup an embedded DS requires use of the configurator, but FBC will already be available from source control so the configurator needs to be avoided.

Running the tests


defaultenv = fbc

am_full_url =
amadmin_pwd = password
am_root_dn =  dc=openam,dc=forgerock,dc=org

Test specific data is handled by the .temper/config file.

Run from temper
$ temper functional-tests --deploy OpenAM-7.0.0-SNAPSHOT.war --hostname --verbose --groups and\(and\(or\(idrepo,smoke\),not\(ssoadm\)\), not\(mock-server\)\) --file-based-upgrade


$ pwd

$ OPENAM_VERSION=7.0.0-SNAPSHOT COMMAND="functional-tests --groups and\(and\(or\(idrepo,smoke\),not\(ssoadm\)\), not\(mock-server\)\)" docker-compose -f docker-compose.yml -f docker-compose.overrides.fbc-upgrade.yml up

Test specific data is handled by .yml and .temperconfig files.

PR Build

CI Build Configuration
CI Build Configuration

Inflexible aspects of the implementation

Because this test implementation relies on a static known FBC the setup can be quite brittle.  The baseline FBC does make use of some placeholders however there are a some significant hard coded values.  Please refer to baseline configuration generation scripts and resources for its definitive status.  The significant values are:

  • ROOT_SUFFIX=dc=openam,dc=forgerock,dc=org
  • ADMIN_PWD=password
  • ADMIN_CONFIRM_PWD=password

Significant hard coded values ^

Unfinished business

  • TODO: Update the links in this page, from the fbc_deployer branch, to master once the code is merged with master.
  • TODO: Move to mandatory test section
  • AME-19111 - Getting issue details... STATUS
  • AME-19254 - Getting issue details... STATUS
  • AME-19294 - Getting issue details... STATUS
  • No labels