wttech / aemc-ansible Goto Github PK

Please document all env variables used by the collection, so that one understands how to configure it if needed

in examples/packer

from /opt/aem to /opt/aemc/aem to allow execution from CWD = /opt/aemc ; right now CWD is /opt which is not looking so nice / logical

sh aemw init --project-kind app_classic

should use/copy file from https://github.com/adobe/aem-dispatcher-docker/blob/main/Dockerfile
instead of having/maintaining a separate https://github.com/wttech/aemc/blob/main/pkg/project/app_classic/dispatcher/Dockerfile

depending on how often that file will be changed

• if rarely - just copy and adapt files from Adobe repo and paste under app_classic setup
• if more frequently - consider some sync mechanism

@tomasz-sobczyk-wttech , @maciej-majchrzak-wttech WDYT?

Currently, aemc-ansible downloads aemc from GitHub. This is not fine for production-type environments. aemc-ansible should allow to deliver aemc binary in other ways, e.g. download from S3 or other place.

• Ansible
  • binary and deps
  • python deps & Mitogen
  • galaxy roles/collections
• Packer

simply add Dockerfile under examples/packer, build image and use it to run packer build
update readme

for activating some page/asset, calling JMX, etc

ansible/ansible#33410

looks like examples/packer is affected by the issue above.

I observed that when AEM is started by wttech.aem.instance module with the start command then the instance is properly started. When some other tasks are run after they are also correctly executed (instance is still running in a standard way). However immediately after when last task is finished, then in crx-quickstart/error.log file it is visible:

which means that the OSGi framework received SIGTERM and the instance is about to stop.

to prevent that we need to spawn AEM instances differently. maybe we could somehow spawn the AEM CLI process differently from Python/Ansible module so that it will not be tracked/ be available on the child process list to terminate by Ansible anymore.

alternatively, AEM CLI could run a start script using nohup or in a similar way to also cut off the parent/child relationship to eliminate that unintended auto-stopping instance behavior.

see: mitogen-hq/mitogen#974 (comment)

https://localheinz.com/articles/2022/01/24/creating-releases-with-github-actions/#content-release-workflow

      - name: "Create release"
        uses: "actions/github-script@v6"
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
          script: |
            try {
              const response = await github.rest.repos.createRelease({
                draft: false,
                generate_release_notes: true,
                name: process.env.RELEASE_TAG,
                owner: context.repo.owner,
                prerelease: false,
                repo: context.repo.repo,
                tag_name: process.env.RELEASE_TAG,
              });

              core.exportVariable('RELEASE_ID', response.data.id);
              core.exportVariable('RELEASE_UPLOAD_URL', response.data.upload_url);
            } catch (error) {
              core.setFailed(error.message);
            }

aem_classic.yml and aem_cloud.yml

Classic should have defined SP installation

Screenshots describing s3 contents

do not download but use installed from rpm gathered from AEM downloads