Use Context ENVs for Slack custom template fails

Ecosystem Orbs
,
1

We have developed a nice custom template for our Slack posts. Ideally, we could use this template across all of our projects without duplicating it. However, when we attempt to read the string from a Context Environment variable, it fails the JQ parsing. Most of the errors are very similar to:

parse error: Invalid numeric literal at line 1, column 16

The actual JSON is pretty straight forward

{
	"attachments": [{
		"color": "#5CBB8B",
		"pretext": "Build #$CIRCLE_BUILD_NUM of *$CIRCLE_PROJECT_REPONAME* project has passed",
		"title": "$CIRCLE_STAGE Results",
		"title_link": "$CIRCLE_BUILD_URL",
		"text": "<< pipeline.parameters.commitMessage >>",
		"footer": "<< pipeline.parameters.authorName >> | $CIRCLE_BRANCH | ${CIRCLE_SHA1:1:6}",
		"footer_icon": "https://github.com/<< pipeline.parameters.authorUserName >>.png?size=32"
	}]
}

We have tried placing the text within the JQ playground at jqplay.org and it parses correctly. We have also tried a TON of ways to evaluate the ENV within our YML file as we have seen ENVs be evaluated differently based on the Orb / command they are being evaluated within. Nothing works.

Screen Shot 2021-06-04 at 9.55.45 AM
Screen Shot 2021-06-04 at 9.55.45 AM610×1340 89.6 KB

We do have a working solution using Pipeline parameters, but that still requires the duplication across projects.

Any suggestions for storing our Slack message template JSON in a reusable way?

2

Hi @MobileVet ,

Sorry to hear you are having this issue.

I believe the problem here is that custom accepts the name of an environment variable.
Could you try passing in the name of the environment variable without $ or quotes?

I was able to replicate the issue on my account and I got a similar error when referencing the environment variable with quotes, but it worked when I removed the quotes.

Storing the template in environment variables should work, but it will make it difficult to update later as you would have to delete the variable and recreate it in order to make updates.

One workaround I have come up with is to store the slack template json in a separate file, and pull in the templates when the build runs.

/slack_template/templates.json


{
    "fail": {
        "text": "Text here for desktop notification",
        "blocks": [
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": "The tests have failed"
                }
            }
        ]
    },
    "pass": {
        "text": "Text here for desktop notification",
        "blocks": [
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": "The tests have passed"
                }
            }
        ]
    }
}

config.yml

version: '2.1'
 
orbs:
  slack: circleci/slack@4.2.1
 
jobs:
  job1:
    docker:
      - image: 'cimg/base:2020.01'  
    steps:
      - checkout
      - run:
          command: |
            echo 'export MY_ORB_TEMPLATE_PASS=$(jq .pass ./slack_template/templates.json)' >> $BASH_ENV
      - run:
          command: |
            echo 'export MY_ORB_TEMPLATE_FAIL=$(jq .fail ./slack_template/templates.json)' >> $BASH_ENV
      - slack/notify:
          channel: slacktest
          event: pass
          template: MY_ORB_TEMPLATE_PASS
      - slack/notify:
          channel: slacktest
          event: fail
          template: MY_ORB_TEMPLATE_FAIL
          
workflows:
  send-notification:
    jobs:
      - job1:
          context: slack-secrets

I am pulling in the json and parsing it with jq, then storing it inside of a variable. Then I am passing that variable name to the slack orb notify step.

For the above example, you would have to include the .json file in every repository, but if you were to make a submodule, you could pull that in for every config.

Let me know if this points you in the right direction, and please feel free to ask if you have any additional concerns or questions!

Best Regards

3

Thanks @aaronclark .
Appreciate the tested suggestion. We will give this a shot when we next revisit our config files.
Cheers,

1 Like
4

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.