--write-git-creds will create a .git-credentials file and configure
git to use it. To allow authentication with your git remotes over https.
To access private repos.
Remove extra quoting and instead add a backslach to each character in
the extra args before appending it to the command.
ex. atlantis plan -- -var key=val will result in:
sh -c "atlantis plan \-\v\a\r \k\e\y\=\v\a\l"
Fixes#697.
Bitbucket Cloud changed their APIs to deprecate the username fields.
This broke how we were checking for approvals. Rather than propagate the
UUID field through the PullRequest model, I use the pull request API
response directly while checking approvers.
To be clear, Atlantis was compatible with 0.12 before this commit, but
this change makes 0.12 the default version *if* users haven't set the
--default-tf-version flag.
Since we're including the command output inside the error, we don't need
to also return the output. This was resulting in the error output being
printed twice.
If there was an error during cloning, we would sometimes print the clone
credentials to the pull request and in the Atlantis logs. This change
ensures we print the redacted clone url.
We also change the redacted clone url to contain "username:<redacted>"
so that if users see the redacted url in logs, they'll know we were
using a credentialed form and so if they try to replicate with curl
they'll know to substitute the correct credentials.
When using --checkout-strategy merge, we were performing the merge
without the --no-ff flag. This meant that if the branch could be merged
via a fast-forward merge (without a merge commit), then later when we
ran git rev-parse HEAD^2 to determine if the repo was at the right
commit, it would fail.
Now we merge with --no-ff which ensures the commit tree will always look
the same and git rev-parse HEAD^2 will always succeed.
Previously, if you were using project names and you had two projects
with the same directory and workspace but different workflows, running
"atlantis apply" would fail. This was because we weren't figuring out
what the project name was for each pending plan.
This change fixes this by extracting the project name from the planfile.
We also handle /'s in the project name by substituting them with '::'.
This allows us to convert them back to /'s when we're figuring out the
project names from the filenames. It's safe to do this because : isn't
an allowed character for project names.
We also remove a final substitution of invalid filename characters
because we rely on the validation of the project names instead which
happens when validating the atlantis.yaml file.
This version changes how we parse custom run steps.
Previously we used the go-shlex library to parse the steps but this
caused users issues because they'd have to use weird escaping.
Now we simply pass the step directy to sh -c without any parsing. The
parsing was unnecessary.
This flag will allow users to specify repo config as json instead of
writing a file to disk. This is useful in deployments where disk access
is more difficult, ex. Docker.
This enables atlantis.yaml in all repos, but by default restricts
certain sensitive keys from being used.
The keys apply_requirements, workflow, and workflows can only be
specified in an atlantis.yaml file if explicitly allowed by a
server side repo config.
The repo config file provides the ability to specify a default set of
workflows, and default values for apply_requirements and workflow to use
use on a per repo basis. It also supports applying to a collection of
repos by using regex to match a repo name.
If more than one repo name matches, the values from last repo matched
are used.
This deprecates the --allow-repo-config option
