Skip to content

Conversation

@mediocretes
Copy link
Contributor

Three significant changes:

  • Modify completions so that if you are using the tfenv setup in our automation repo, you get completions from the right version of terraform
  • Set a flag allowing rails to bypass some MacOS fork restrictions, necessary for parallel testing in some critical cases
  • Add some prototype in-emacs test code for Nate to play with.

…nathan so far, but maybe someday other people will want to use this. eterm never dies, baby.
…to get forking to work properly in hte docraptor tests. as things labeled 'unsafe' go, it is fairly safe. We have seen this before and this was the solution then, too. Read more: https://stackoverflow.com/questions/52671926/rails-may-have-been-in-progress-in-another-thread-when-fork-was-called
Copy link

@fzhunt fzhunt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know anything about emacs configs, so I can't tell if that file looks good or not, but I am curious if there's a better way to define the terraform autocomplete besides overriding a previous line.

complete -C $(brew --prefix)/bin/terraform terraform
fi

complete -C /opt/homebrew/Cellar/tfenv/3.0.0/versions/1.4.2/terraform terraform
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line overrides the if statement above, so should that if statement (and its corresponding code in script/setup) be removed? Or is there a more variable way to do this that will autocomplete with whichever one we wanted, instead of overriding it every time?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Terraform installs to different locations depending on home-brew vs tfenv and intel vs apple chips. At this point, we can probably just assume both apple silicon and tfenv are in use and just use that for completions. Of course, we should probably use the default or highest version in tfenv, rather than just insisting on 1.4.2...

I might break these into 2 or 3 PRs. For the purposes of my current project, the line I really NEED is

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

The rest is just stuff I've had locally but which isn't really required for day to day.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah since we're the only ones running this code, and we all have Apple Silicon, that's a safe bet. Besides this everything looks good, so I'll approve it.

@mediocretes
Copy link
Contributor Author

I have extracted the parts of this that will be required soon into #43

Why is this change needed?
--------------------------
This function is useful when identifying heisentest issues and generally grinding through things that need multiple runs. It is not, however, very user friendly, especialliy when running tasks with lots of output.

How does it address the issue?
------------------------------
This adds a failure counter (which counts non-zero exit statuses, perfect for `rails test`) and also outputs a loop counter in between runs so you can see how far along you are.

Any links to any relevant tickets, articles, or other resources?
---------------------------------------------------------------

Any screenshots?
----------------

Did you complete all of the following?
--------------------------------------
- Run test suite?
- Add new tests?
- Consider security implications and practices?
…rename some variables to make it more friendly to read.
… export. Now we actually want that terraform completion in there. Not doing these as two seperate PRs from the start was a mistake, and this is me eating my vegetables.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants