Associate terraform state changes with pipeline/job/MR/commit whenever possible

added to epic &4563

added Category:Infrastructure as Code devopsconfigure [DEPRECATED] groupconfigure [DEPRECATED] typefeature labels

mentioned in issue #262085 (closed)

changed the description

@nicholasklick @tigerwnz @mattkasa Let's continue the discussion here!

Are we thinking an MVC could be: When using gitlab-terraform apply we link that apply to its parent pipeline via an (extra api hit or request header)? A pipeline should already be linked to a branch/commit etc I assume?

I think this makes sense as a first iteration. As a technical nitpick, we'll probably want to link to the specific job within the pipeline (we can then get pipeline info from the job).

Extra API hit or use request header: IMO if we can get this to work automatically without requiring an extra API call we should go with that. An extra endpoint could allow for extra customisation by the user later on, though I'm not sure what exactly they might want to do here yet.

A pipeline should already be linked to a branch/commit

Yes, the job (pipeline) links us to everything else.

If a valid CI_JOB_TOKEN is used for state authentication, then can we definitely look up the job used?
If yes, would relying on this be an acceptable MVC? Do we anticipate a users wanting to use a different token?

then can we definitely look up the job used?

Technically, yes, because this is how we identify the user in the first place (to check permissions etc). However it may prove complicated as this lookup is quite far down into the authentication logic. Just now I've noticed that @current_authenticated_job gets set though, maybe we can use that?

would relying on this be an acceptable MVC

Users may be using a personal access token here which will prevent this from working, but I still think this is good enough as a first iteration - I have a feeling trying to add anything else will be a bit more complicated.

@tigerwnz I agree with you, and would go forward with assuming that they don't use a personal access token. If they do, then we won't show the related data.

Just now I've noticed that @current_authenticated_job gets set though, maybe we can use that?

I tested this out in !45347 (merged), it works as expected with only minor modifications to the authentication code.

@tigerwnz Given your open MR, I'm going the set the milestone for %13.6 as a Stretch goal. If you manage to merge it, I'll be happy. If you don't, I won't mind. :)

As of !45347 (merged) we are capturing the job that created each state version (if present). The details aren't available to the frontend yet, this will come in a later merge request.

!47339 (merged) and !47347 (merged) provide the final backend components, the remainder is frontend only.

Ok. Thanks!

added sectionops label

changed the description

changed milestone to %13.7

mentioned in merge request !45347 (merged)

mentioned in issue #267147 (closed)

changed milestone to %13.6

added Stretch direction labels

mentioned in merge request !47339 (merged)

mentioned in merge request !47347 (merged)

changed the description

@mvrachni Could you add here the final designs for the terraform state list page, please.

@nagyv-gitlab Added the designs in the proposal section in the description. We still need to review the tooltip text to finalise and sign off the designs. You can provide your comments in the design issue here: #262916[Versions-no_actions-tooltips.png]