[Trigger Pipeline] Previous deployment status cache returned in artifacts workspace

Forge Component
(2)
Published on 21 Jun by Rui Mendes
2 votes
Published on 21 Jun by Rui Mendes

When deploying we seem to get allways all deployment status logs (so the current including the previous once) back from OutSystems.

What do we have to do to only get the one related to the current run?

The list below contains the outsystems status logs (the staging info) from multiple days, not only the last one. This causes problems for us.

Hello Daniël,


How are you managing the pipeline workspace for each run?


In every run, the pipeline will fetch information from LifeTime and will store it into the Artifacts folder. 

Can you check if you are deleting the Artifacts folder at the end of each pipeline run?


Best regards,

Duarte

Hi Duarte,

Yes we are deleting the artifacts at the end.

But it looks like LifeTime returns not only the artifacts of the current deployment but also from the previous once.

Regards,

Daniel

Hello Daniël,


Everytime the pipeline executes the deploy_latest_tags_to_target_env (python) method to a target environment (ex: Testing) the following artifacts are created inside the deployment_data folder:

  • <deployment_key>.cache - for the new deployment plan that includes the applications versions of the scope of the pipeline
  • <deployment_key>.status.cache - for each deployment plan that has been created since the day prior to the execution

All of this information is archived for troubleshooting purposes although we are considering renaming the cache files to better distinguish between the deployment we want to run from the prior ones.


If the amount of information causes problems, and since all of the information can be checked anytime in LifeTime, we advise to change the pipeline configuration so it won't archive some of these files.


Best regards,

Duarte


Hi Duarte,

Thank you for your answer.

We do want those 2 files, we store them as evidence on a jira ticket, which number is entered as a step in the pipeline. We need to store all evidence log (so also the BDD test results), outside Jenkins or OutSystems lifetime, as the customer requires that all evidence of the deployment should be accesseable also when Jenkins or OutSystems is not available to use.

The problem we face is, that at the end of the pipeline we remove all the artifacts. 

When we start a new pipeline run, that when we collect the artifacts to store in the JIRA ticket, it does not only contain the .<deployment_key>.cache and <deployment_key>.status.cache, but also of previous deployments

That is the part we don't understand.

Regards,

Daniel

Solution

Hi Daniël,


Everytime we want to deploy something within the pipeline flow, and before the new deployment plan (that contains the application versions to deploy) is created, we need to guarantee that the target environment does not have any ongoing deployment. For that matter the pipeline fetches and checks the status of the previous deployment plans before the deployment execution (and writes those statuses as individual artifact files that can be used for latter troubleshooting).


Because the <deployment_key>.cache and <deployment_key>.status.cache artifacts file names are generated with the deployment_key, we are considering renaming them so they become more readable and also to better distinguish between the current deployment status from the prior ones.


Best regards,

Duarte


Solution

Yes renaming them would be great, please could the target environment name be part of the name? 

Yes, we aim to include that information as part of the name.

Duarte Castaño wrote:

Yes, we aim to include that information as part of the name.


Thanks