search

alpheios-project / documentation

Alpheios Developer Documentation
0 stars 0 forks source link

add the qa build process #28

Closed balmas closed 4 years ago

balmas commented 4 years ago

@kirlat can you take a look at what I have added here about the QA build process? It seems to be working as written.

In addition to the outstanding issues noted in the doc, I have the following questions:

  1. is there any real reason to update package.json with the build number for embed-lib and components? Since webpack is injecting it into the built code, I'm not sure it is necessary. We are a little out of sync with this in the UI, because have a constructor argument which takes a build number as well as a package version, and for embed-lib and components this is now redundant. I am leaning towards just not putting it in package.json.

  2. It seems to me that deleting and recreating the qa branch each time we do a qa build is more of a hassle than it's worth. The risk is that somehow qa will get out of sync with dev but that shouldn't normally happen if we follow the workflow properly.

What do you think about these?

kirlat commented 4 years ago 
1. is there any real reason to update package.json with the build number for embed-lib and components? Since webpack is injecting it into the built code, I'm not sure it is necessary. We are a little out of sync with this in the UI, because have a constructor argument which takes a build number as well as a package version, and for embed-lib and components this is now redundant. I am leaning towards just not putting it in package.json.

The only reason we're doing this (in my understanding) is because we need a unique version number in order to publish embed-lib and components to npm. So if we're not going to publish, we can not append the build number postfix to the version field of package.json. But if we do, I think it's the only way to make npm registry not to reject the package because of the same version number with the one already in registry. What do you think?

balmas commented 4 years ago 
1. is there any real reason to update package.json with the build number for embed-lib and components? Since webpack is injecting it into the built code, I'm not sure it is necessary. We are a little out of sync with this in the UI, because have a constructor argument which takes a build number as well as a package version, and for embed-lib and components this is now redundant. I am leaning towards just not putting it in package.json.

The only reason we're doing this (in my understanding) is because we need a unique version number in order to publish embed-lib and components to npm. So if we're not going to publish, we can not append the build number postfix to the version field of package.json. But if we do, I think it's the only way to make npm registry not to reject the package because of the same version number with the one already in registry. What do you think?

oh... right. So many different variables here. Yes, we need this for publishing to npm. I will note that in the documentation. Thank you!

kirlat commented 4 years ago 
2. It seems to me that deleting and recreating the qa branch each time we do a qa build is more of a hassle than it's worth. The risk is that somehow qa will get out of sync with dev but that shouldn't normally happen if we follow the workflow properly.

I think it is probably not necessary to remove a qa branch when we finished testing. But we may delete it if we want to as well. On my opinions, both ways are fine, we can start working with qa being not deleted (as it is simpler) and see how well will it work. What do you think?

kirlat commented 4 years ago

oh... right. So many different variables here. Yes, we need this for publishing to npm. I will note that in the documentation. Thank you!

You're right, there are so many variations we have! I'm thinking maybe it's better to put to docs on a per-package level (i.e. maybe to the README.md of each package) or it might be very hard not to get lost in it.

Maybe it will also be a good idea to put a link to the git workflow docs in the documentation repository into the README of each package. Otherwise someone might miss the fact that there is another important document(s) in a separate repository that describes a development workflow. What do you think?

balmas commented 4 years ago 
2. It seems to me that deleting and recreating the qa branch each time we do a qa build is more of a hassle than it's worth. The risk is that somehow qa will get out of sync with dev but that shouldn't normally happen if we follow the workflow properly.

I think it is probably not necessary to remove a qa branch when we finished testing. But we may delete it if we want to as well. On my opinions, both ways are fine, we can start working with qa being not deleted (as it is simpler) and see how well will it work. What do you think?

yes that is what I was thinking.

balmas commented 4 years ago

oh... right. So many different variables here. Yes, we need this for publishing to npm. I will note that in the documentation. Thank you!

You're right, there are so many variations we have! I'm thinking maybe it's better to put to docs on a per-package level (i.e. maybe to the README.md of each package) or it might be very hard not to get lost in it.

Maybe it will also be a good idea to put a link to the git workflow docs in the documentation repository into the README of each package. Otherwise someone might miss the fact that there is another important document(s) in a separate repository that describes a development workflow. What do you think?

yes definitely. Wanted to get them right here before editing the READMEs. I think the README should have the short version of steps to follow with a link to this fuller documentation of the overall workflow.