Fork me on GitHub
#circleci
<
2021-08-25
>
borkdude12:08:40

I was following this bit of documentation, but I was fooled by the lower case letter in the environment variable $npm_TOKEN which should probably be capital letters: https://circleci.com/blog/publishing-npm-packages-using-circleci-2-0/

borkdude12:08:34

I have some trouble building certain jobs only when I pushed a tag:

workflows:
  version: 2
  ci:
    jobs:
      - test:
          filters:
            tags:
              only: /.*/

      - deploy:
          requires:
           - test
          filters:
            tags:
              only: /^v.*/

borkdude12:08:49

It seems the deploy tag is always running, regardless of a tag or not

borkdude12:08:25

The example at "Git Tag Job Execution - Deploy on tagged commit" here, also seems wrong: https://circleci.com/blog/publishing-npm-packages-using-circleci-2-0/

borkdude12:08:12

Adding:

branches:
              ignore: /.*/
solved the "always running"

borkdude12:08:59

but now it seems to not appear anymore in case of a tag... aaaaah

borkdude12:08:07

ffffffff.... how am I going to test this without making a gazillion useless releases?

borkdude12:08:14

so what I'm doing, I'm executing this:

bump-version (do (shell "npm version patch")
                   (shell "git push --atomic origin main"
                          (str "v" (:version (json/parse-string (slurp "package.json") true)))))

borkdude12:08:30

which pushes a new git tag + commit

borkdude12:08:54

and then circleci should always execute the test job + only the deploy job in case of such a tag

lread12:08:46

I've been mostly in GitHub Actions these days... Do I remember @slipset generalizing circleci tag based deploy support for clj-commons though?

borkdude12:08:07

See the top commit: it has no tag, yet the deploy job gets executed 😠

borkdude12:08:24

This is the config I currently have:

workflows:
  version: 2
  ci:
    jobs:
      - test
      - deploy:
          requires:
           - test
          filters:
            tags:
              only: /^v.*/

lread12:08:47

annoying!

borkdude12:08:34

yeah, I've looked at that

borkdude12:08:57

but I read now that those filters are applied in an OR fashion..

borkdude12:08:04

it's really confusing me

lread12:08:52

oh... OR... that seems counter-intuitive to me.

borkdude12:08:56

I've read several forum entries about this too, it doesn't make sense to me today. Maybe I should just try github actions for this

borkdude12:08:07

hmmm, it seems this is working now:

workflows:
  ci:
    jobs:
      - test:
          filters:
            tags:
              only: /.*/
      - deploy:
          requires:
           - test
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^v.*/

gordon16:08:07

These rules are evaluated top-down to work out if a job should be included or excluded If a tag is pushed: • and the push did not push a branch • and there is a tags: only filter • and the tag matches that filter then the job will be included in the workflow. If a tag is pushed: • and the push did not push a branch • and there is a tags: ignore filter • and the tag does not match that filter then the job will be included in the workflow. If a tag is pushed: • and the push did not push a branch then the job will be removed from the workflow. If a tag is pushed: • and the push also pushed a branch • and there is a branches: only filter • and the branch matches that filter then the job will be included in the workflow. If a tag is pushed: • and the push also pushed a branch • and there is a branches: ignore filter • and the branch name does not match that filter then the job will be included in the workflow If a tag is pushed: • and the push also pushed a branch • and there is a tags: ignore filter • and the tag does not match that filter then the job will be included in the workflow If a tag is pushed: • and the push also pushed a branch then the job will be included in the workflow

lread12:08:34

I'm not grokking why, are you?

lread12:08:58

Seems non-obvious to me too. Someone will enlighten us, I'm sure.

borkdude12:08:59

I think I'll just not use any of this filter stuff and just check programmatically what the current tag is

lread12:08:36

For rewrite-clj on GHA, I took the approach of https://github.com/clj-commons/rewrite-clj/blob/main/doc/04-maintainer-guide.adoc#releasing. Not sure if this concept works for circleci or for your versioning scheme.

borkdude12:08:28

I'm taking the bb tasks approach here which runs npm version which creates a git tag which is then pushed atomically with the new commit

borkdude12:08:44

and then CI can inspect whether the current commit related to a tag or not

borkdude12:08:50

and then deploy or not

lread12:08:09

ah ok... that sounds good.

borkdude12:08:12

so anyone who can commit, can trigger a release

lread12:08:46

Yeah, for rewrite-clj I preferred to restrict release trigger to repo owner.

glenjamin17:08:06

Are the credentials available to all branches?

borkdude17:08:07

@glenjamin the npm credentials? that wasn't the problem, the problem was that the filters didn't work for me, but I figured it out a different way

glenjamin17:08:24

Sorry, I should have been clearer: I was asking for a different reason. have you got it set so that untrusted builds can access those creds? The config file alone isn’t enough to protect credentials

borkdude17:08:36

you mean the "PRs can access secrets" kind of thing right? No I never do that

gordon16:08:07

These rules are evaluated top-down to work out if a job should be included or excluded If a tag is pushed: • and the push did not push a branch • and there is a tags: only filter • and the tag matches that filter then the job will be included in the workflow. If a tag is pushed: • and the push did not push a branch • and there is a tags: ignore filter • and the tag does not match that filter then the job will be included in the workflow. If a tag is pushed: • and the push did not push a branch then the job will be removed from the workflow. If a tag is pushed: • and the push also pushed a branch • and there is a branches: only filter • and the branch matches that filter then the job will be included in the workflow. If a tag is pushed: • and the push also pushed a branch • and there is a branches: ignore filter • and the branch name does not match that filter then the job will be included in the workflow If a tag is pushed: • and the push also pushed a branch • and there is a tags: ignore filter • and the tag does not match that filter then the job will be included in the workflow If a tag is pushed: • and the push also pushed a branch then the job will be included in the workflow