Cannot force regeneration of metadata on RightScript

[erikhjensen]

https://github.com/rightscale/right_st/blob/a4850023a2c74acefb0dd43c46a3611c87fb0efa/scaffold.go#L50

We are working with your consulting services and I just tried to force scaffolding to regenerate the metadata in the following use-case.

User has an RS that they want to clone and test a new version,
User copies the RS, adds their username/initials as a prefix
(if they uploaded now, despite the new filename, it'd obey metadata and not create that new clone)
So we add the force parameter to the tool, and it does not re-generate the metadata.

in your code, it looks like you have the following logic:
if metadata exists
if not force
show them a message
--no else for "if not force"
else generate fresh metadata.

i've written my own code to clear the metadata but based on your readme, i'm wondering if this code just has a bug whereby it's missing the else condition to overwrite metadata for a forced file which already had metadata.

[douglaswth]

I'm not sure I fully understand your use-case, but it seems like perhaps you should be using the --prefix option when uploading a RightScript. This will prepend the user's prefix (which could be their username/initials) to the name of the RightScript that it uploads just as it seems you want.

[erikhjensen]

I’d be willing to try that and change my workflow. But can you please comment on the scaffold function and the force-flag, why it won’t regenerate metadata for a file which already has metadata? That appears contrary to the function’s readme/help-notes. In talking to RightScale/Flexera consulting services, they outlined the following use case which I’m implementing on our git repo CI/CD. 1) Create branch in git for feature development 2) Identify the file which will require a personal prefix, and which will be enhanced 3) Make a local copy, add the prefix manually to the file name so that you can edit it while still having its ancestor side by side 4) Check into my branch and have CI/CD (or the developer manually) upload that using right_st. I’m struggling with forcing the metadata to be re-generated, when I trace your code, it looks like it will explicitly not regenerate metadata for a file with existing metadata even if scaffold –force is supplied. right_st rightscript scaffold [<flags>] <path>... Add RightScript YAML metadata comments to a file or files Flags: -f, --force: Force regeneration of scaffold data. The change in workflow you’d suggested looks to me like the following 1) User makes a branch 2) Edits the rightscript in question 3) CI/CD realizes it’s on a branch and calls upload w/ the prefix flag so that the rightscale file can exist in the catalogue side by side w/ its ancestor. I’ve been talking to your consulting groups around the best practices but they don’t quite have the ‘factory model’ best practice in a state that they can convey to me and that’s why I’d come up w/ the use case I’ve depicted above. From: Douglas Thrift [mailto:notifications@github.com] Sent: Tuesday, September 03, 2019 3:18 PM To: rightscale/right_st Cc: Jensen, Erik; Author Subject: Re: [rightscale/right_st] Cannot force regeneration of metadata on RightScript (#71) I'm not sure I fully understand your use-case, but it seems like perhaps you should be using the --prefix option when uploading a RightScript. This will prepend the user's prefix (which could be their username/initials) to the name of the RightScript that it uploads just as it seems you want. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#71>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AID7KRHDHNM5LWFUQ4AGBWTQH3IAXANCNFSM4ITKX6YA>.

…

________________________________

--------------------------------------------------------- If you wish to no longer receive electronic messages from this sender, please respond and advise accordingly in your return email. This email and its contents are private and confidential, for the sole use of the addressees. If you are not an intended recipient, copying, forwarding or other distribution of this email or its contents by any means is prohibited. If you believe that you received this email in error please notify the original sender and delete this communication and any copies immediately. Petro-Canada is a Suncor Energy business. 150 – 6th Avenue S.W., Calgary, Alberta, Canada, T2P 3E3 (Corporate Head Office) / www.suncor.com

------------------------ Si vous ne voulez plus recevoir de messages électroniques de cet expéditeur, veuillez l’en aviser en répondant à ce courriel. Ce courriel et son contenu sont privés et confidentiels, et sont destinés à l’usage exclusif des destinataires. Si vous n'êtes pas le destinataire prévu, toute reproduction, transfert ou autre forme de diffusion de ce courriel ou de son contenu par quelque moyen que ce soit est interdit. Si vous croyez avoir reçu ce courriel par erreur, veuillez en aviser l’expéditeur original et supprimer cette communication et toutes ses copies immédiatement. Petro-Canada est une entreprise de Suncor Énergie. 150 – 6th Avenue S.W., Calgary, Alberta, Canada, T2P 3E3 (siège social) / www.suncor.com

[douglaswth]

Okay, I think I see where the confusion is arising: the force only updates detected inputs and attachments in the script and not the name or description. The assumption there is that perhaps you have added some new variables or paths while updating your script, so you would force the scaffold to happen in order to add those new inputs or attachments to the metadata while if you wanted to change the name or description of something, you would edit the metadata comment directly.

Given that you would already be using Git (or any other version control system), I definitely suggest the second approach you've listed:

1.  User makes a branch
   

2.  Edits the rightscript in question
   

3.  CI/CD realizes it’s on a branch and calls upload w/ the prefix flag so that the rightscale file can exist in the catalogue side by side w/ its ancestor.
   

Especially if the end goal is to eventually merge the feature branch and upload the merged script in the main lineage.

[erikhjensen]

Gocha.. I thought there was a good chance it was user error. I’d suggest clarifying the documentation during your next release. From: Douglas Thrift [mailto:notifications@github.com] Sent: Tuesday, September 03, 2019 4:28 PM To: rightscale/right_st Cc: Jensen, Erik; Author Subject: Re: [rightscale/right_st] Cannot force regeneration of metadata on RightScript (#71) Okay, I think I see where the confusion is arising: the force only updates detected inputs and attachments in the script and not the name or description. The assumption there is that perhaps you have added some new variables or paths while updating your script, so you would force the scaffold to happen in order to add those new inputs or attachments to the metadata while if you wanted to change the name or description of something, you would edit the metadata comment directly. Given that you would already be using Git (or any other version control system), I definitely suggest the second approach you've listed: 1. User makes a branch 2. 1. 4. Edits the rightscript in question 5. 1. 7. CI/CD realizes it’s on a branch and calls upload w/ the prefix flag so that the rightscale file can exist in the catalogue side by side w/ its ancestor. 8. 1. Especially if the end goal is to eventually merge the feature branch and upload the merged script in the main lineage. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#71>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AID7KRAW2NCZNFGOL5E5YDTQH3QFHANCNFSM4ITKX6YA>.

…

________________________________

--------------------------------------------------------- If you wish to no longer receive electronic messages from this sender, please respond and advise accordingly in your return email. This email and its contents are private and confidential, for the sole use of the addressees. If you are not an intended recipient, copying, forwarding or other distribution of this email or its contents by any means is prohibited. If you believe that you received this email in error please notify the original sender and delete this communication and any copies immediately. Petro-Canada is a Suncor Energy business. 150 – 6th Avenue S.W., Calgary, Alberta, Canada, T2P 3E3 (Corporate Head Office) / www.suncor.com

------------------------ Si vous ne voulez plus recevoir de messages électroniques de cet expéditeur, veuillez l’en aviser en répondant à ce courriel. Ce courriel et son contenu sont privés et confidentiels, et sont destinés à l’usage exclusif des destinataires. Si vous n'êtes pas le destinataire prévu, toute reproduction, transfert ou autre forme de diffusion de ce courriel ou de son contenu par quelque moyen que ce soit est interdit. Si vous croyez avoir reçu ce courriel par erreur, veuillez en aviser l’expéditeur original et supprimer cette communication et toutes ses copies immédiatement. Petro-Canada est une entreprise de Suncor Énergie. 150 – 6th Avenue S.W., Calgary, Alberta, Canada, T2P 3E3 (siège social) / www.suncor.com