With the codeontap process treating all configuration as code, all iterations of the configuration should be treated as a potential production configuration. Using this idea a given configuration should be validated to make sure that it can be deployed and if it can, then it should be tagged as a potential configuration that could move up to production.

This follows the same process where a successful build commit is passed to the configuration as a reference of a successful build and treated as code which could move to production.

With our deployment process in the first environment, only the deployment unit that was specified for the deployment is deployed using the configuration which in turn means a subset of the deployment is validated.

This means that when configuration/code is ready to be released to a new environment, deployment needs to be validated across all of the configuration. So the work of the second/staging environment should be to take the production environments current state, apply the new configuration in its entirety, reporting on how the configuration has changed the state of the environment. Using this report, a deployment can be tagged as a release if the desired state has been achieved.

This means that the staging environment becomes staging for both the application code and for the infrastructure config. If a change is required to environment specific configuration the change has to be moved up through the environments as a new deployment to verify that this works across all environments.

gen3-automation has a few calls to the Github REST api to determine the git commit for a given tag. However they Github are deprecating the basic auth setup that we are currently using to do this

You recently used a password to access an endpoint through the GitHub API using Java/1.8.0_222. We will deprecate basic authentication using password to this endpoint soon:

https://api.github.com/repositories/216596747/pulls/234/commits

We recommend using a personal access token (PAT) with the appropriate scope to access this endpoint instead. Visit https://github.com/settings/tokens for more information.

Thanks,
The GitHub Team

When running the manageDocker.sh script from a container based codeontap jenkins agent. The local registry management fails with the error:

16:25:12 [EnvInject] - Variables injected successfully.
16:25:12 [1-Pull-Image] $ /bin/bash /tmp/jenkins5010240702152116372.sh
16:25:12 /opt/codeontap/automation/jenkins/aws/manageDocker.sh: line 262: : bad substitution
16:25:12 
16:25:12 (Fatal) Can't log in to 340127619209.dkr.ecr.ap-southeast-2.amazonaws.com
16:25:12 Build step 'Execute shell' marked build as failure
16:25:16 Finished: FAILURE

Confirmed that the configuration is ok but it looks like the issue might be with using a taskRole for aws permissions.

Extend manageUnits to iterate through a list of accounts, with the current value of "ACCOUNT" being the default.

The list is provided in an environment variable the same as the list of levels or units is provided.

This way manageAccount can process multiple accounts in one run - a common occurrence when adjusting things like IP whitelisting.

Currently when a release is being prepared if the image format is not set the image defaults to a docker based image.
Given the larger variation of image types that we now have, the default should be to throw an exception and fail the process.

This aligns with the idea that on the initial release you need to specify the image format that will be used.

Delete updateBuildReference.sh and validateUpdateBuildReferenceParameters.sh. They are superceded by the equivalent plural based filenames.

Update

${RELEASE_MODE_PROMOTION})
    defineSetting "RELEASE_MODE_TAG" "p${RELEASE_TAG_BODY}-${SEGMENT}"
    defineSetting "ACCEPTANCE_TAG" "${RELEASE_TAG_BODY}-${FROM_SEGMENT}"
    ;;

The RELEASE_MODE_TAG should also use "FROM_SEGMENT" so it reflect the release from the lower environment that was accepted.

I think the cleanest thing is to define ACCEPTANCE_TAG, and then define RELEASE_MODE_TAG as "p${ACCEPTANCE_TAG}-${SEGMENT}", to reflect the tag that was promoted and the target segment for te promotion.

At present, all the build scripts call manageImages.sh directly. In order to permit multiple builds per build job, for instance a node build as well as a swagger build, manageImages.sh needs to be made its own job step and explicitly included into the definition of any build jobs.

Since this will break existing job definitions, it will need to be included int he next breaking change.

The profile name for docker-compose integration tests networks should be unique per build as it may run simultaneously for builds on master and PR branches.

Adding a random part to the profile name will solve the issue.

Add a process which can be used to copy a blueprint from a segment level repo to a centralised location, the tenant infrastructure repo.

This would allow for a consolidated set of blueprints to be provided to documentation generation or for lookup services for linking in the future

manageBuildReferences.sh is not correctly recognising JSOn format build references. Looks like the regexp checking for a string starting with "{" isn't working..

Remove support for legacy "slice:" terminology

• Use HEREDOCS for usage
• Use HERESTRINGS instead of "echo ... | "
• Use input redirection not "cat" command for a single input file
• Direct errors to stderr (>&2)

For static site generation processes a number of dependencies are required to generate the static content itself. Tools like Jekyll or sphinx have docker based images which include these dependencies and output the static content to a directory on the docker image

To support this style of static content generation we need a build job which will

• Run and build a docker image based on a dockerfile in the repository
• bind mount to a nomiated location in the docker image
• Pull out the static content and create an spa.zip which can be used with our SPA codeontap component

This would allow for us to have object store based static sites which are significantly cheaper, and more scalable than running the HTTP server provided in these docker images

While setContext sets up credentials for ACCOUNT, when processing multiple accounts in a single build the credentials need to be refreshed for each change of account..

Reformat the contents of automationServerSetup.md to make it readable.