0

I'd like to write a cli command to integrate all actions I have to do when I complete a local working session on my (react-js) project:

  • increase by one the version of the project (in version field in package.json file)
  • add all changes I did to git index
  • commit changes to git (with a message)
  • tag the version with new version number and commit message
  • pull from remote
  • push to remote (including tags)

The push to remote (github or gitlab, for example) will initiate a CI/CD build, too.

What I came up with until now is something as ugly as this:

m="debugging tag & version"; npm version --no-git-tag-version --force patch && git add . && git commit -m "$m" && git tag -a v`node -p "require('./package.json').version"` -m "$m" && git pull --no-edit && git push --follow-tags

The main drawback of this is that it forces a double build on remote, probably because it is pushing twice... But I can't see why, since I do not know in depth all the interested commands.

Can you give some advise to correct my solution, or suggest a different strategy?

UPDATE: I include my GitLab's CI configuration file (.gitlab-ci.yml) here, it it can be of any help...

variables:

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

build site:
  image: node:12
  stage: build
  script:
    - yarn install --no-progress 2> >(grep -v warning 1>&2)
    - yarn build
  artifacts:
    expire_in: 1 week
    paths:
      - build/

# we test only on master branch to speed up CI/CD while developing, for the moment...
unit test:
  image: node:12
  stage: test
  only: 
    - master
  script:
    - yarn install --no-progress 2> >(grep -v warning 1>&2)
    - yarn test

# we only deploy on master and developing branches; for other feature branches,
# we work locally only and then merge into developing or master.
deploy:
  image: alpine
  stage: deploy
  only: 
    - master
    - developing
  before_script:
    - apk add --no-cache rsync openssh sshpass
  script:  
    - if [ -z "$CI_COMMIT_BRANCH" -o "$CI_COMMIT_BRANCH" = "master" ]; then DEPLOY_PATH="marketplace"; else DEPLOY_PATH="marketplace.test"; fi
    - echo "On branch $CI_COMMIT_BRANCH, deploying to $DEPLOY_PATH"
    - sshpass -p $DEVEL_PASS rsync -az --delete --no-perms --no-g -O -e "ssh -o StrictHostKeyChecking=no" build/ $DEVEL_USER@$SERVER_NAME:/var/www/$DEPLOY_PATH/
 
phd
  • 82,685
  • 13
  • 120
  • 165
MarcoS
  • 17,323
  • 24
  • 96
  • 174
  • 1
    The only command that is going to write on the remote side is `git push`. Probably the `--follow-tags` is causing a double write on the remote. Can you try removing the follow-tags options and see if you still have the double build? – Yusef Maali Jul 01 '20 at 09:44
  • 1
    Yes, it works, no more double build! Unfortunately without `--follow-tags` flag I do not have the tag on remote... – MarcoS Jul 01 '20 at 10:32

1 Answers1

1

git push pushes branch(es) and commits. On top of that --follow-tags pushes tags that point to the pushed commits.

Every CI assumes that code behaves differently related to tags. Even if the very code is the same the code in CI configuration checks if the current commit is tagged and do something, usually release package(s).

Because of this by default every CI executes at least two runs for every push with tags — one for every branch (some are configured to run tests on every new pushed commit so the entire run count could be even higher) and one for every tag.

If you're absolutely sure your code behave the same even if there is a tag you can disable separate run with tags in CI configuration. The usual way is to allow CI run tests only on branches. You didn't named your CI so I cannot give more specific advice.

phd
  • 82,685
  • 13
  • 120
  • 165
  • I use gitlab's CI/CD. I add to my question my .gitlab-ci.yml, if it can help... – MarcoS Jul 01 '20 at 13:45
  • I add that the issue happens on branches (currently `developing` branch), did not yet test on master.... – MarcoS Jul 01 '20 at 13:53
  • @MarcoS See https://stackoverflow.com/a/60523901/7976758 `except:…- tags`. https://stackoverflow.com/search?q=%5Bgitlab-ci%5D+skip+tags – phd Jul 01 '20 at 14:17
  • Perfect, thanks. Can you give me an example how could application code behave different depending on tags? I can't imagine how it could... – MarcoS Jul 01 '20 at 19:18
  • The usual different behaviour as I've said is to release a package for a tag. For example [I release Python packages](https://pypi.org/project/Cheetah3/3.2.5/#files) for Linux, MacOS X and w32/w64. Linux/OSX releases are produced at [Travis CI](https://github.com/CheetahTemplate3/cheetah3/blob/a6fb302197444eb5bc42f74da5d272eeb97582d7/.travis.yml#L75), w32/w64 releases at [AppVeyor](https://github.com/CheetahTemplate3/cheetah3/blob/a6fb302197444eb5bc42f74da5d272eeb97582d7/appveyor.yml#L95); releases are produced only on tags. This is just an example — the same code behaves differently on tags. – phd Jul 01 '20 at 20:00
  • CI don't know what parts of code could depend on absence or presence of a tag so they don't assume anything an run tests on every tagged commit twice — test commit as a part of a branch and the same commit as tagged commit. If a particular user wants to disable one of the tests CI have flexible ways to configure their pipelines. – phd Jul 01 '20 at 20:09
  • I see. You mean CI yml code depends on tags, if I understand correctly, not application code, as I thought... – MarcoS Jul 02 '20 at 04:49