build(branching): sw-450 restructure, rename

[cdcabrera]

What's included

• build(branching): sw-450 restructure, rename
  • CONTRIBUTING, document branching, tags, release
  • custom_release, align release branching for travis
  • dependabot

Notes

• @diegomaranhao
• On QE approval the process will be as follows
  • ci branch will be renamed dev branch
  • main branch will stay the same
  • stage branch will be deleted
  • qa branch will be deleted
  • this PR will be merged into the main branch new prod branch (we've already created it) and the commit rebased across all remaining branches down to dev
  • and that will leave us with 2 branches, dev and main
• @mirekdlugosz does default branch for this new process matter? we're considering making the new dev branch the default

How to test

Example

...

Updates issue/story

sw-450

[codecov-commenter]

Codecov Report

Merging #956 (3d13c99) into prod (ea56c40) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             prod     #956      +/-   ##
==========================================
+ Coverage   93.92%   93.94%   +0.02%     
==========================================
  Files         129      129              
  Lines        4030     4030              
  Branches     1578     1578              
==========================================
+ Hits         3785     3786       +1     
+ Misses        227      226       -1     
  Partials       18       18              

Impacted Files	Coverage Δ
src/common/helpers.js	100.00% <0.00%> (+1.66%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea56c40...3d13c99. Read the comment docs.

[cdcabrera]

Ok @mirekdlugosz I think this aligns a bit more to a future where there may only be 2 branches, just dev and main. Hopefully this aligns to what you were thinking too...

It is fantastically minimal effort on the maintainer side of things, so I'm all for it since it automagically syncs most of the lower environments (mostly because we're using a single branch, main). We apparently had all the parts, just needed to rearrange them a little.

Basically

• dev is where we develop, not necessarily going to be checked beyond unit tests, dev tests
• main is where the automation is, and releases are controlled by tags at least until we're no longer using Travis (and we're reasonably sure it'll work based on Travis' logic)

I've outlined the process here

• Release candidates, https://github.com/RedHatInsights/curiosity-frontend/blob/3d13c99e3e65759f943b57601dc272090bd4d1b1/CONTRIBUTING.md#release-candidates-prod-beta
  • releases candidate tags would follow, v[x].[x].[x]-rc.[x]
• Releases, https://github.com/RedHatInsights/curiosity-frontend/blob/3d13c99e3e65759f943b57601dc272090bd4d1b1/CONTRIBUTING.md#release-prod-stable
  • release tags would follow v[x].[x].[x]

And the logic can be seen here... this is sort of testable by running the script directly ...just make sure you comment out lines 11 and 12. Went through a variety of combinations to confirm, happy path is below...

$ export TRAVIS_BRANCH="v2.5.0"; export TRAVIS_BUILD_STAGE_NAME="Stable"; export TRAVIS_COMMIT_MESSAGE="chore(release): hello world"; bash ./.travis/custom_release.sh

curiosity-frontend/.travis/custom_release.sh

Lines 11 to 12 in 3d13c99

	rm -rf "./${BUILD_DIR}/.git"
	.travis/release.sh "${DEPLOY_BRANCH}"

• https://github.com/RedHatInsights/curiosity-frontend/blob/3d13c99e3e65759f943b57601dc272090bd4d1b1/.travis/custom_release.sh

[mirekdlugosz]

Agreed, that looks pretty simple. dev is automatically deployed to stage-beta, main follows dev and is deployed to stage-stable. Every now and then we add tag to somewhere in main to deploy that commit to prod-beta. To release to prod-stable we need both tag and specific commit message, which is probably stronger requirement than what I would have put, but I don't see it as something that needs to be changed.

I played with a script locally and it does seem to do what we expect to do, i.e. it won't accidentally release something to prod environments.

I think we can proceed with that. Once this is merged, I will create PR in app-interfaces repo, so pr_check script is taken from dev, and build script is taken from main.