graasp / graasp-deploy Goto Github PK

Since we might not include type checking in some repos (ie. builder) it would be nice to test it from a workflow.

Remove unused caller templates as they will be moved to .github repository

References:

• https://docs.github.com/en/actions/security-guides/automatic-token-authentication
• https://github.blog/changelog/2022-09-08-github-actions-use-github_token-with-workflow_dispatch-and-repository_dispatch/

Use the jacobsvante/tag-major-minor-action action to do so.

Those can be used with v3

If the deployment failed (most probably because the container is faulty) the container will be infinitely mounted.
The solution would be to trigger a new deployment instruction with the latest working container (a previous untagged master?).

Formatting of the new detected version is broken after #62

See bellow:

They are all show on a single line when they should be on multiple lines.

Add workflow to perform smoke tests, that will also be included as part of the continuous delivery pipeline

We should use versions (tags) and create releases of the workflows to ease the use and update of re-usable workflows.
Although using the commit SHA is the most secure and stable way according to the docs, it means it is less easy to know if the workflow uses the latest version.

So instead of graasp/graasp-deploy/.github/workflows/cintegration-s3-apps.yml@a5e6f97c18c86d97e3e8f15b27e4d898746327cf we could use graasp/graasp-deploy/.github/workflows/cintegration-s3-apps.yml@v1

• Ability to conditionally deploy stuff
• Specify versions for each service
• Must also provide other services (redis, database)
• Config specified by e.g. json file

Implementations

• Single docker-compose.yml with conditionals in env variables
  • pro: requires only docker, cons: rely on env vars "hacks" to conditionally disable services
• Generate docker-compose from intermediate representation (e.g in Typescript)
  • pro: can generate other kinds of tasks (reuse with some CDK for AWS), con: require node

Issues

• Docker-compose already defined in graasp: how to reuse?

Use migration tool to version migrations of each plugin:

• https://github.com/db-migrate/node-db-migrate
• represent constraints, etc

Integrate into #1 and #2 to transform into deployment steps

Generate CloudFormation SDK / CDK directives from higher-level intermediate representation (e.g. Typescript) with dependency graph (see #1)

Starting in version 3, the workflow uses node 16 by default.
Node 12 was used previously and is now deprecated.

Some workflows would need it. For instance, both cypress and type checking need yarn install.
I think it's also valid for all the workflows that require to build.

Here is an example of used cache https://github.com/graasp/graasp-deploy/blob/main/.github/workflows/cypress.yml

Sometimes we don't want to push an app at the same time as everything.
It would be nice to have a "select" between yes/true to decide exactly the stack we want to trigger.

For reference: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Modification should be:

- name: Set output
  run: echo "::set-output name={name}::{value}"

To:

- name: Set output
  run: echo "{name}={value}" >> $GITHUB_OUTPUT