Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Reliable passing build plan by a separate file + minor changes #13

Merged
merged 22 commits into from
Jun 9, 2020

Conversation

ahlinc
Copy link
Contributor

@ahlinc ahlinc commented Jun 9, 2020

Description

  • Added passing of build plan by a separate file.
    Also in an archive_plan resource the build plan data are seen.
  • Added docker_pip_cache variable to speedup a python requirements repeatable installations.
  • Renamed: lambda.py -> package.py
    It seems that lambda.py is a confusable name and we have the
    package.tf file so it's better to name the helper as package.py
    to make it associated as a companion script for the package.tf file.

ahlinc added 20 commits June 9, 2020 08:44
If the `docker_pip_cache = true` then "${artifacts_dir}/cache/pip" is used
for storing downloaded pip packages.

  WARNING: Because pip runs inside of docker it runs with a uid=0 and gid=0
  permissions, so files in the "${artifacts_dir}/cache/pip" directory will have
  a root user permissions. To remove the "${artifacts_dir}" directory entirely
  a sudo prefixed command is required, like: `sudo rm ${artifacts_dir} -r`.

It is also possible to speicify another location for the pip cache
directory by setting the docker_pip_cache variable to a string,
like: `docker_pip_cache = "/tmp/pip_cache"`
To be independant from lambci docker images do chown just current
working directory because there is no directory changes and all packages
installation just happens to cwd.
So a local_file resource will be only a safe measure
in case of a situation like:
  1. Store a terraform plan to a file.
  2. Remove all zip and plan files from artifacts dir.
  3. Run `teraform apply` from the stored plan file.
…name

Hints:
 * When there is a goal to don't have deferred data sources
   which will be read on the Terraform's apply phase. And also
   design a module that wouldn't unexpectedly start to produce
   such read deferals, it is needed to:
   * Separate all possible variables that may be defined by the end user
     into two sets whether it makes sense to define its content as a result
     of some resource or not. And haven't use any of such variables that
     may have a value derived from resources as an input values of any
     data sources introduced by the module.
   * Another approach is to explicitly claim for the end user that
     some scope of variables should be statically defined and can't
     use any interpolations or assignments that include values from any
     resource results. And let to know what to expect if someone want to
     don't obey for such restrictions.
ahlinc added 2 commits June 9, 2020 10:34
It seems that lambda.py is a confusable name and we have the
package.tf file so it's better to name the helper as package.py
to make it associated as a companion script for the package.tf file.
@antonbabenko antonbabenko changed the title Reliable passing build plan by a separate file + minor changes feat: Reliable passing build plan by a separate file + minor changes Jun 9, 2020
@antonbabenko antonbabenko merged commit ec7a787 into terraform-aws-modules:master Jun 9, 2020
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants