meta-dts workflow can delete ~/.ssh/config in some exceptional situations

[iwanicki92]

Component

Dasharo Tools Suite

Device

other

Dasharo version

No response

Dasharo Tools Suite version

No response

Test case ID

No response

Brief summary

Stopped/failed CI action can delete ~/.ssh/config which will lead to failure on next run

How reproducible

Always

How to reproduce

• Push tag or rerun workflow that's run on tag push
• Cancel immediately (before second job starts/DTS finishes building)
• Repeat step 1

Expected behavior

Previous workflow errors shouldn't influence current one

Actual behavior

workflow fails because previous action change expected state
https://github.com/Dasharo/meta-dts/actions/runs/9997346441/job/27634154969

Screenshots

No response

Additional context

https://github.com/Dasharo/meta-dts/actions/runs/9996958212/job/27633519716
and
https://github.com/Dasharo/meta-dts/actions/runs/9997346441/job/27634154969

• Second job creates config-old: ci.yml
• Third job (cleanup) is always run (even on failures) ci.yml
  • deletes config
  • moves config-old to config

If workflow is stopped before second job then config is deleted in third and next step fails because there is no config-old to move.
Next run fails on second job because in previous job config was deleted but not recreated.

Solutions you've tried

Not tested but quick fix would be to remove rm -f ~/.ssh/config.
Next step (mv ~/.ssh/config-old ~/.ssh/config) would still fail in this case but config wouldn't be deleted.

[PLangowski]

How about moving cp ~/.ssh/config ~/.ssh/config-old to the beginning of the first workflow? That would reduce the probability of config-old not existing.

[macpijan]

How about simply create from scratch a config for this job, and do not touch original ~/.ssh/config at all?

This seems like the core of the problem, unnecessary complexity.

Refer to the manual:

       -F ssh_config
               Specifies an alternative per-user configuration file for ssh.  This option is directly passed to ssh(1).

[m-iwanicki]

@PLangowski I guess it's ok, this way clean job would most likely always succeed, but I would still remove rm part and leave only mv.
Or you can do it as @macpijan said and maybe create copy of ~/.ssh/config if it's needed.

[PLangowski]

@m-iwanicki the PR has been merged. Can you close this issue or is there something more to be done?

[m-iwanicki]

@PLangowski Closed, I wonder why it wasn't closed automatically when PR was merged.